UBA030801 


DESIGN  FOR  MULTICS  SECURITY  ENHANCEMENTS 


<? 


J.  Whitmore 
A.  Bensoussan 
P.  Green 
D.  Hunt 
A.  Kobziar 
J.  Stern 


/ >' 


Honeywell  Information  Systems,  Inc. 
575  Technology  Square 
Cambridge,  MA  02139 


I 


December  1973 


Approved  for  public  release; 
distribufion  unlimifed. 


r'" 


Prepared  for 


DEPUTY  FOR  COMMAND  AND  MANAGEMENT  SYSTEMS 
ELECTRONIC  SYSTEMS  DIVISION 
HANSCOM  AIR  FORCE  BASE,  MA  01731 


LEGAL  NOTICE 

When  U.  S.  Government  drawings,  specifications  or  other  data  are  used  for  any 
purpose  other  than  a definitely  related  government  procurement  operation,  the 
government  thereby  incurs  no  responsibility  nor  any  obligation  whatsoever;  and 
the  fact  that  the  government  may  have  formulated,  furnished,  or  in  any  way  sup- 
plied the  said  drawings,  specifications,  or  other  data  is  not  to  be  regarded  by 
implication  or  otherwise  as  in  any  manner  licensing  the  holder  or  any  other  person 
or  conveying  any  rights  or  permission  to  manufacture,  use,  or  sell  any  patented 
invention  that  may  in  any  way  be  related  thereto. 


OTHER  NOTICES 


Do  not  return  this  copy.  Retain  or  destroy. 


This  technical  report  has  been  reviewed  and  is  approved  for 
publication. 


F.  WAH  USAF  ‘ 

Project  Officer 

Air  Force  Data  Services  Center 


ROGBR  R.  SCHELL,  MA. 
Pqyject  Engineer 


FOR  THE  COMMANDER 


3 V 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Data  Entered) 

F~  j ■/  REPORT  DOCUMENTATION  PAGE 


rI>  ES D-tTR-74-176  j 

— ' V T.T,  j 

: c , pESIG N FOR  MULT ICS~  * 
"'SECURITY  ENHANCEMENTS* 


12.  GOVT  ACCESSION  NO. 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 
1.  RECIPIENT'S  CATALOG  NUMBER 


S.  TYNE  ON  REPORT  • PERIOD  COVERED 


h ■ 'i 


j/'.y^fhitmore , A.  Bensoussan,  P ./Green, 

!i.  ■^D./Hui^t/'  A.  Kobziar j J.  Stern 

Y per FSWUm-o-oPG »fiu«  WTm e and  address 

Honeywell  Information  Systems,  Inc. 

575  Technology  Square  /^ 

Cambridge.  MA  02139 

II.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Deputy  for  Command  and  Management  Systems 
Electronic  Systems  Division 

Honscom  Air  Force  Base.  MA  Q173I 

I*  MONITORING  AGENCY  NAME  & ADDRESSfl/  dlllorot >!  Irani  Controlling  Otllco) 


16.  DISTRIBUTION  STATEMENT  (ol  thlt  Roport) 

Approved  for  public  release;  distribution  unlimited. 


>7.  DISTRIBUTION  STATEMENT  (ol  the  ebetract  entered  In  Block  20,  II  dllferent  from  Report) 


18.  SUPPLEMENTARY  NOTES 


F 1 9628-73-  D-0087 


to.  PROGRAM  ELEMENT.  PROJECT.  TASK 
AREA  * WORK  UNIT  NUMBERS 


Task  0004AA 

12.  REPORS  BATe 

J ! jPeqfrmtottr  19’ 

13.  NCTWtft R OF  PA*^-— =="^*‘ 



IS.  SECURITY  CLASS,  (ol  thlt'ltfo'ttf 


1973  ! 


UNCLASSIFIED 

ISa.  DECLASSIFICATION/DOWNGRADING 
SCHEDULE  ^ 


* t U 


19-  KEY  WOROS  ( Continue  on  reveree  side  il  neceeeary  and  Identify  by  block  number) 


computer  security 
security 
access  control 


Multics 
containment 
operating  system 


K 


h0  ABSTRACT  '(Continue  on  reveree  tide  If  neceeeary>  and  Identify  by  block  number) 


The  results  of  a 1973  security  study  of  the  Multics  computer  system 
are  presented  detailing  requirements  for  a new  access  control  mech- 
anism that  would  allow  two  levels  of  classified  data  to  be  used 
simultaneously  on  a single  Multics  system.  The  access  control 
policy  was  derived  from  the  Department  of  Defense  Information 
Security  Program.  The  design  decisions  presented  were  the  basis 
for  subsequent  security  enhancements  to  the  Multics  system.  ^ 
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Pr  e f ac  e 


This  report  aocuments  the  results  of  a 1973  stuay  to 
identify  a set  of  security  enhancements  for  Honeywell's  Multics 
operating  system.  These  enhancements  were  derived  fro*  the 
Department  of  Oefense  Information  Security  Program.  The  purpose 
of  these  enhancements  was  to  permit  users  of  two  different 
security  levels  to  simultaneously  access  classified  information 
stored  on  the  Multics  system  at  the  Air  Force  Data  Services 
Center  (AFOSC).  This  report  served  as  a design  document  for  the 
subsequent  implementation  of  the  security  enhancements  for  use  at 
the  AFOSC. 

The  implementation  of  the  cesign  was  based  upon  the 
“non-mal  lclous**  user  concept.  This  concept  is  predicated  upon 
the  assumption  that  none  of  the  user  oooulation  woulo  attemot 
malicious*  concerted  efforts  tc  circumvent  the  enhanced  security 
controls.  The  issues  of  guaranteeing  the  impenetrability  of  the 
security  enhancements  were  not  completely  addressed*  and  the 
report  manes  no  claim  to  the  system's  i moene trab  1 1 i t y . However* 
the  proposes  security  controls  are  thought  to  be  representative 
of  those  controls  which  could  be  provided  on  a certifiably  secure 
system.  The  issues  involved  in  the  development  of  a certifiably 
secure  system  are  the  subject  of  a separate  effort  soonsoreo  by 
the  Information  Systems  Technology  Applications  Office  of  the  Air 
Force's  Electronic  Systems  Division. 

During  the  course  of  the  implementation  of  the  security 
enhancements  proposed  in  this  report*  several  minor  deslsn 
changes  were  made.  This  reDort  has  not  been  updateo  to  reflect 
♦hese  changes.  This  report  should  be  taken  neither  as  a precise 
description  of  the  enhanced  Multics  system  implemented  for  AFOSC 
nor  as  a description  of  Honeywell's  Multics  procuct--curr ent  or 
future. 
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INTRODUCTION 


Honeywell  participated  In  a |cint  Security  Design  Analysis  with 
the  Air  Force  to  evaluate  the  requirements  for  providing  a 
two-level  security  system  on  Multics.  The  primary  ooa  I was  to 
develop  a high  level  design  for  modifications  to  the  Multics 
system  to  support  a two-level  security  environment.  This  effort 
is  a first  step  on  the  path  to  a certified  secure  system. 


The  analysis  was  conducted  by  a team  composed  of  represen 
from  groups  active  in  the  computer  security  field.  Team 


t at  Ives 
members 


werei 


USAF  AFOSC 


USAF  ESO 


MITRE  Corp. 


Honeywell  0S0 


Honey we  1 1 CISL 


Caot.  F.  Hah  Leonq 
Caot.  Oave  Schafer 

Malor  Roger  Schell 
Lt.  Paul  Karger 

Steven  Lloner 
Morrie  Gasser 
Edmund  8urke 

Jerold  Whitmcre 
Paul  Green 
Douglas  Hunt 
Jerry  Stern 

Andre  Bensoussan 
Andrew  Kobziar 


The  Security  Design  Analysis  covered  the  oeriod  from  10  July  1973 
through  8 October  1973.  The  minutes  of  the  weekly  meetinqs  are 
not  P3rt  of  this  report. 

This  report  was  written  by  Honeywell  personnel  with  review  and 
guidance  from  the  other  team  members.  Responsibi  I ty  for  errors 
and  omissions  remains  strictly  with  Honeywell. 

Suggestions  and  desijn  decisions  contained  in  this  report  are  not 
binding  on  either  the  Air  Force  or  on  Honeywell. 


... 


\ 
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1.  SCOPE  OF  THE  SECURITY  DESIGN  ANALYSIS 


1*1  Identification  and  Authority 


The  authority  for  this  Security  Design  Analysis  is  contained 
in  contract  number  F19628-73-0-QQ87.  The  Design  Analysis 
task  has  been  conducted  as  a Joint  effort  of  Honeywell 
Information  Systems  Inc.*  Oata  Systems  Operations;  Air 
Force  Oata  Services  Center;  Air  Force  Electronics  Systems 
Oivision  < MCI T » ; and  HITRE  Corporation. 


1.2  Purpose 


1.2.1  Task  Description 


The  primary  task  is  to  examine  the  problems  and  implications 
of  operating  the  HoneyMell  Mullics  System  in  a restricted 
multi-level  security  mode  for  Secret  and  Top  Secret  cleared 
users.  The  primary  criterion  to  be  used  in  evaluating 
solutions  to  various  problems  is  that  the  system  should 
provide  reasonable  assurance  that  no  Top  Secret  information 
can  be  compromised  to  a Secret  cleared  person.  This  means 
that  on  a single  Multics  system,  within  design  constraints, 
there  should  be  no  Information  oaths  between  users  having 
different  clearances  which  do  not  exist  between  users  of 
physically  separate  dedicatee  computer  systems. 

with  these  problems  in  mind,  the  team  looked  for 
modifications  to  the  Multics  Operating  System  which  will 
correct  these  problems,  insofar  as  possible,  and  yet 
maintain  the  current  user  interface  ano  functional 
capabilities  of  Multics.  Specific  design  goals  lncluccdt 

1.  Oeslgn  to  the  requirements  of  the  Air  Force  Oata 
Services  center  RFP  Noi  F 19628-73-R-0024. 

2.  Oeslgn  the  basic  security  controls  as  an  integral  part 
of  the  Multics  system. 

3.  Provide  a design  which  may  be  extended  for  additional 
security  enhancements. 
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4.  Provide  a generalized  design  that  nay  be  adaoted  for 
other  OoO  and  commercial  applications  of  the  security 
system* 


1*2*2  Specific  Exclusions  from  the  Design  Analysis 


Certain  problems  of  multi-level  security  ADP  operation  and 
extensions  of  basic  multi-level  security  controls  *»ere  Known 
at  the  start  of  the  Design  Analysis  and  mere  specifically 
excluded*  These  are  described  in  the  fol lowing  paragraphs* 


1*2. 2.1  Cer t 1 f icat ion 


The  task  of  certifying  the  correctness  of  any  implementation 
of  the  multi-level  security  system  design  proposed  in  this 
report  is*  of  course*  beyono  the  scope  of  the  Design 
Analysis.  No  hardware  modifications  are  in  fact  requirea. 
In  spite  of  a conceptually  correct  design,  an  actual 
implementation  could  conceivably  contain  programming  errors 
which  cause  the  system  to  behave  incorrectly.  Hence* 
absolute  security  cannot  be  claimed  without  certification. 
Consequently,  in  choosing  among  design  alternatives, 
consideration  has  been  given  to  facilitating  the  future  task 
of  certification* 


1 • 2 • 2 • 2 The  Trojan  Horse  Problem 


A computer  system  which  provides  sharing  of  user  written 
procedures  is  susceptible  to  a "Trojan  Horse  attack"  by  a 
malicious  user.  A Trojan  Horse  Is  a procedure  which 
provides  a potentially  useful  function  to  attract  use  by  a 
person  having  access  privileges  not  possessed  by  the  author 
of  the  procedure.  The  Trojan  Horse  program  detects  such  use 
and  performs  unauthorized  or  unwanted  functions  which  would 
allow  the  author  of  the  procedure  to  obtain  information  to 
which  he  did  net  otherwise  have  access  or  to  perform  acts  of 
sabotage  which  would  not  otherwise  be  possible. 

A general  solution  to  the  Trojan  Horse  problem  is  excluded 
from  the  scooe  of  the  Oesigr  Analysis.  However*  reducing 
the  information  paths  between  users  of  different  clearance 
levels  is  within  the  scooe  of  the  Oesign  Analysis.  The 
issue  of  sabotage  from  a Trojar  Horse  is  accepted  with  a low 
expectation  of  occurrence  since  all  users  of  the  system  will 


be  cleared  and  issunec  trustworthy*  An  act  of  sabotage  at 
the  AFOSC  Installation  will  have  considerably  less  severe 
consequences  than  at  certain  other  Military  sites  such  as 
those  having  a command  and  control  environment. 


1* 2*2*3  High-Water  lark 


. ne  design  extension  of  having  users  start  work  at  a low 
level  with  automatic  or  requested  upgrade  to  a higher  level 
as  more  sensitive  data  is  needed  was  specifically  excluded 
from  the  scope  of  the  Design  Analysis.  This  extension  is 
commonly  described  as  a “high-water  mark**  capability. 


1.2.2.4  Program  Trustwor thiness 


The  ability  to  reduce  the  system  recognized  clearance  of  a 
user  who  may  attempt  to  access  sensitive  material*  based  on 
the  clearance  level  of  procedures  executed  in  a user's 
process*  l>s  commonly  described  as  the  “trustworth  iness“ 
capability*  This  is  one  means  to  reduce  the  potential 
damage  by  a Trojan  Horse  attempting  to  perform  sabotage. 
The  "trus twor tniness“  capability  is  specifically  excluded 
from  the  scope  of  the  Oesign  Analysis. 


1«2*2.5  Hardware  Modifications 


Modi f icatl ons  to  the  hardware  of  the  Honeywell  Model  6180 
system  and  its  oerioheral  devices  were  specifically  excluded 
from  the  scope  of  the  Oesign  Analysis.  Ho  hardware 
modifications  are  in  tact  required. 


1.2.3  Ena  Product  of  the  Oesigr  Analysis 


This  document  is  the  end  product  of  the  Oesigr  Analysis.  It 
describes  the  requirements  for  operating  a Multics  system  in 
a restricted  multi-level  security  mode  for  Secret  and  Too 
Secret  users  working  in  a closed  secure  environment. 

The  requirements  are  translated  into  a functional  design  of 
modifications  to  the  Multics  system  needed  to  provide  this 
restricted  multi-level  security  operation. 

In  addition,  the  user  limitations  and  potential 
operat  iona I /adminl str st i ve  problems  internal  ard  external  to 
the  system  are  outlined. 
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r This  document  is  expected  to  be  the  basis  of  the  proposal 

for  the  implementation  phase  of  the  security  controls  as 
k T described  in  CORL  Item  A010  of  Air  Force/Honey  Me  1 1 contract 

number  Fi9628-73-0-d087. 
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2*1  Air  Force/Honeywe I I contract  number  F19628-73-G-QQ87 

This  contract  provides  the  authority  for  the  Security  Design 
Analysis.  The  documentation  requirements  for  the  final 
report  and  the  allowed  deviations  from  the  format  are 
specified  in  this  contract.  The  AFOSC  Multlcs  RFP  No* 
F 19628-7 3-P-O 0 2<*  is  Included  in  the  contract.  Annex  5-1  of 
that  RFP  defines  the  primary  requirements  for  Hultlcs 
security  controls. 


2.2  OoO  5200. 1-R  Information  Security  Program  Regulation 

(Describes  the  military  security  system  and  the 
responslbi 1 1 ties  of  personnel  who  fall  withlr  its 
Jurisdiction. 


2-3  AFR  205-1  Information  Security  Program  (USAF) 
Implements  OoO  5200. 1-R 


2.**  OoO  52  GO  .28  Department  of  Oefense  Directive*  Security 
Requirements  for  Automatic  Oata  Processing  (AOP)  Systems 

Qefines  the  security  requirements  for  orocessinq  classified 
data  on  an  AOP  system  (See  2.5). 


2.5  DoO  52QQ.28-M  Manual  of  Techniques  and  Procedures  for 
Implementing*  Oeac t l v s t i ng » Testing*  and  Evaluating  - Secure 
Resource  Sharing  AOP  Systems. 

This  is  the  manual  which  outlines  the  details  cf  the  general 
requirements  specified  in  OoO  5200*28. 


OoO  5200.28  and  OoO  520C.28-M 
mandatory  documents  to  be  followed 
the  time  the  AFOSC  RFP  was 
requirements  have  been  met  as 
designing  the  Multics  Security 
Section  3. 


were  not  identified  as 
for  the  Multics  system  at 
Issued.  However,  the 
closely  as  possible  in 
Controls  oescrlbeo  in 
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2.6  MIL-STO-483  Appendix  VI  Para  60* 


Computer  Program 


(Paragraph  2.11.  Section  3 of  the  standard  has  been 
expanded  in  this  document  to  provide  a form  of  presentaticn 
better  suited  to  the  material. 


2*7  Honeywell  Multics  documenrat ior 

The  following  documents  are  mentioned  here  as  a source  cf 
background  information  concerning  the  Multics  system. 

Multics  Programmers*  Manual 
Introduction  (AG90) 

Reference  Guice  < AG9i ) 

Commands  and  Active  Functions  (AG92) 

Subroutines  (AG9.5) 

Subsystem  Writer's  Guice  (AK92> 

Project  Administrator's  Manual  (AK5i> 

System  Administrator's  Manual  (AK50) 

PL/I  Language  Manual  (AG94I 
Multics  Virtual  Memory  (AG95I 
The  Multics  System  <AK27» 

The  order  numbers  given  above  (e.g.  AG90)  should  be 

specified  when  ordering  these  cocuments  from  Honeywell. 


2.8  General  references 

The  following  documents  are  mentioned  here  as  a source  of 
background  information  concerning  computer  security  and*  in 
particular*  military  computer  security. 

Multics  Evaluation*  J.  P.  Anderson*  E SO- TR-7 3-27 e * 
Electronic  Systems  Oivision  (AFSC)*  L.  G.  Hanscom 
Field*  Bedford*  MA « October  1973. 

Design  ana  Certification  AoproacM  Secure 


Secure  Computer  Systems!  Mathemat 1 ca I Foundations*  0. 
E.  Bell  ana  L.  J.  LaPadula*  ES0-TR-73-278*  Vol  I* 
Electronic  Systeas  Olwislon  (AFSCI*  L.  G.  Manscow 
Field*  Bedford*  HA*  November  1973* 


Coaputer  Secure  Research  and  Bevel opaent  Requirements* 
S.  8.  Lipner*  MTP-1A2*  The  HITRE  Corporation*  Bedfora* 
HA*  February  i973« 


Preliminary  Notes  on  tte  Design  of  Secure  Military 
Computer  Systems*  R.  R.  Schell*  P.  J*  Ooaney*  and  G.  J* 
Popek,  MC I-73-l » Electronic  Systems  Oivision  (AFSCI*  L. 
G.  Hanscoa  Field*  Bedford*  MA*  January  1973* 


Concept  of  Operation  for  Handling  I/O  in  a Secure 
Computer  at  the  Air  Force  Oaf  a Services  Center  (AFDSO* 
E.  L.  Burke*  ES0-TR-74-H3  * L.  G.  Hanscom  Field* 
Bedford*  HA*  October  1973. 
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SECURITY  REQUIREMENTS  FOR  AIR  FORCE  DATA  SEPVICES  CENTER 


: | 

i : 
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The  Air  Force  Oata  Services  Center  has  a requirement  to 
provide  AOP  resources  and  services  for  the  processing  cf 
unclassified  through  Top  Secret  data  to  support  Headquarters 
USAF  and  the  Office  of  the  Secretary  of  the  Oeoartment  of 
Oefense.  In  providing  this  capability*  the  AFQSC  is 
responsible  for  tne  security  of  the  classified  data 
processed  on  their  computer  systems* 

Most  contemporary  shared  computer  systems  are  not  secure 
because  security  was  not  a mandatory  requirement  of  the 
initial  hardware  and  software  design.  The  military  has 
achieved  reasonably  effective  physical*  communication*  and 
personnel  security.  Hence*  the  primary  computer  security 
problem  is  that  of  information  access  controls  in  the 
operating  system  and  supporting  hardware.  Essentially*  =n 
effective  means  for  enforcing  very  simple  protection 
re  I at  1 onshlos  (e.g.  user  clearance  level  must  be  greater 
than  or  equal  to  the  classification  level  of  accessed 
information)  is  needed*  however*  solutions  to  some  of  the 
more  complex  protection  problems  such  as  mutually  suspicious 
processes  are  not  required. 

In  current  Dractice  at  AFOSC*  computer  security  is  achieved 
by  dedicating  an  entire  computer  system  to  users  clearec  to 
a particular  security  level.  This  approach  results  in  poor 
utilization  of  computer  resources*  and  hence*  high  costs  for 
data  Drocessing, 

Providing  a two-level  security  operating  mode  on  the 
Honeywell  6180  Multics  System  will  be  the  first  steo  toward 
fully  utilizing  the  resources  of  a single  comouter  system 
serving  a user  community  with  mu  I ti o I e- I e ve I security 
requirements* 

The  decision  to  design  and  implement  a two-level  security 
system  for  the  Air  Force  Oata  Services  Center  is  predicated 
on  our  capability  to  provide  those  security  controls  that 
will  reduce  the  rlsH  of  release  of  Too  Secret  informatlor  to 
Secret  users  to  an  acceptable  level.  No  claim  is  being  mace 
as  to  the  ability  of  the  security  system  to  withstand 
penetration  attempts.  The  approval  test  that  the  system 
will  be  sub|ected  to  prior  to  its  installation  will  only 
demonstrate  the  existence  of  security  controls.  It  is 
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3«1  System  Operating  Environment  Definition 
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3«i.i  HardMare/Sof tmare  Interface 

The  central  processing  unit  used  Is  the  Horeywel I Model 
6180.  The  operating  system  is  Multics,  with  such 
modifications  and  extensions  as  result  from  this  Security 
Oeslgn  Analysis  and  the  system  programming  task  that  will 

foil  ON. 

A full  description  of  the  Honeymel I 6i8Q  hardware  and  the 
Multlcs  softNare  is  beyono  the  scope  of  this  coeument.  The 
interested  reader  is  referred  to  the  publications  listed  in 
Section  2*7  for  such  detailed  descriptions. 


3.1.2  User  Interface 

The  user  interface  is  the  appearance  the  system  presents  to 
the  user.  To  the  greatest  degree  possible*  this  appeerance 
Nil  I remain  the  same  as  current  Multlcs. 

Functions  available  to  the  user  n1 I I be  identical  to  current 
Multlcs  Nhere  feasible*  and  eculvalent  in  most  other  cases. 


3.1.3  Definition  of  AFOSC  Controlled  Environment 

The  central  computer  facility  Nil  I be  a Top  Secret 
controlled  area. 

All  remote  terminal  areas  Nil  I be  physically  protectee  *o 
the  Top  Secret  level  even  though  they  may  be  used  as  Secret 
controlled  areas. 

The  communications  betveen  the  central  computer  facility  and 
all  remote  terminal  areas  Ni II  be  via  Top  Secret  encrypted 
data  lines. 

Top  secret  clearances  Nil!  be  required  for  all  persons 
(operators*  system  programmers*  system  maintenance 
personnel*  field  engineers  and  others!  Nho  reed  physical 
access  to  the  central  computer  facility*  or  any  haroNare* 
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data  lines  or  terminal  connections  in  the  reeote  teraina! 
areas;  or  data  and  control  lines  between  the  central 
coaputer  facility  and  the  remote  terainal  areas* 

All  programmers*  analysts*  users  or  persons  who  are 
registered  to  use  the  Hultlcs  system  at  AFQSC  wilt  have 
either  a Secret  or  a Top  Secret  clearance* 

All  I/O  operations  will  be  performed  by  central  site 
operating  personnel*  No  user  will  be  permitteo  to  mcunt  his 
own  tapes*  disks  or  other  media. 


3*1*4  Definitions 
access 


The  ability  and  the  means  tc  approach*  communicate  with 
(input  to  or  receive  output  from)*  or  otherwise  make  use  of 
any  material  or  component  in  an  ADP  System. 

In  the  military  security  system*  a person  may  be  granted 
access  to  an  object  only  if  his  clearance  level  is  greater 
than  or  equal  to  the  classification  level  of  the  object; 
his  clearance  category  set  contains  all  categories  in  the 
category  set  of  the  object;  and  he  has  the  proper  "neeo  to 
know**  in  reference  to  the  object. 
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AOP  (Automatic  Oat a Processing) 

An  assembly  of  computer  equipment.  facilities*  personrel* 
software  and  procedures  configured  for  the  purpose  of 
classifying*  sorting,  calculating*  computing*  summarizing* 
storing*  and  retrieving  data  and  information  with  a minimum 
of  human  Intervention. 


anonymous  user 

An  anonymous  user  is  an  unregistered  user  of  the  Multlcs 
system  whose  oersonid  (see  be)  cm)  is  "anonymous**;  in  other 
words*  his  p^rsonid  is  unknown  to  the  system.  An  anonymous 
user  may  or  may  not  be  required  to  furnish  a password  in 
order  to  gain  access  to  the  system. 


branch 

A branch  is  a component  of  a directory  which  describes  an 
immediately  Inferior  segment  or  directory. 
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breach 


The  successful  and  repeatable  defeat  of  security  controls 
Mith  or  without  an  arrest  which  if  carried  to  consuaeat ior * 
could  result  in  a penetration  of  the  systee.  Examples  of 
breaches  are! 

Operation  of  user  code  lr  aaster  node; 

Unauthorized  acquisition  of  userid  and  oassworc;  and 

Accessing  a file  without  using  prescribed  operating  systee 
"•chan isms. 


category  set  (also  see  access) 

In  reference  to  a person*  a category  set  refers  to  the  set 
of  coapartments  a person  is  eligible  to  access.  (The 
maximum  number  of  compartments  within  a single  system  is 
limited  to  sixteen.)  A compartment  in  this  context  is  an 
orthogonal  subdivision  of  the  classification  levels.  A 
compartment  is  like  a formal  need  to  know  author! zat ion  to 


Information 


certain  topic  without  consideration 


classification  level. 

In  reference  to  documents*  files  or  other  objects*  a 
category  set  refers  to  the  possible  Information  sources  used 
to  create  the  ob)ect.  Thus  a category  set  with  several 
categories*  or  compar tments*  would  indicate  that  the  object 
should  be  handled  with  the  extra  caution  accorced  to  objects 
which  would  intersect  the  sensitive  areas  of  each  of  the 
categories  in  the  set. 


classification  level  (also  see  access) 

One  of  an  ordered  set  of  levels  which  aescribes  the 
sensitivity  of  the  information  to  which  it  refers.  (The 
maximum  number  of  levels  within  a single  system  is  limited 
to  seven.)  Only  information*  documents,  data*  equipment  or 
other  objects  have  classification  levels.  Persons  need  the 
correct  clearance  to  access  information  at  ary  level  higher 
then  Unclassified. 

When  c ompartmented  security  is  used*  a classification 
includes  both  the  level  and  the  category  set  associated  with 
an  object. 
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clearance  (also  see  access) 

The  eligibility  of  a person  (or  process)  to  access 
information  of  a certain  classification  level  (or  loNer). 
For  example*  a person  with  a Secret  clearance  is  eligible  to 
access  Information  with  classification  levels  Unclassified 
to  Secret*  but  may  not  have  access  to  Top  Secret 
information. 

When  compar tmented  security  is  used*  a clearance  also 
Includes  the  categories  a person  is  eligible  tc  access. 

In  addition  to  the  eligibility  afforded  a person  by  his 
clearance*  he  must  also  have  the  need  to  knom  the  classified 
information  before  he  is  given  access. 


daemon  (SysOaemon) 

Certain  Multics  processes  are  dedicated  to  performing 
supervisory  functions*  such  as  handling  I/O  requests  and 
backing  up  the  file  system.  These  processes  are  called 
daemon  processes  and  run  with  the  SysOaemon  projectld. 


directory 

A directory  is  a segment  in  the  Multics  storage  system 
hierarchy  maintained  by  the  supervisor  which  contains 
information  about  immediately  Inferior  segments.  A 
directory  contains  a list  of  branches  analogous  to  a table 
of  contents. 


fixed  level  property 

In  order  that  no  breach  of  security  occur  within  the 
computer  system  environment,  it  is  sufficient  that  no 
process  be  permitted  to  read  information  classified  above 
its  clearance,  nor  be  permitted  to  write  information 
classified  below  its  clearance.  This  principle  is  krcwn  as 
the  fixed  level  property.  (It  has  also  been  called  the 
“♦-property"  in  some  of  the  referenced  literature) 


Initializer  process  (system  control  process*  answering  service) 


The  initializer  process  is  a special  process 
certain  system-controlling  functions.  In 
initializes  the  Multics  environment,  monitors 
terminals,  creates  all  other  processes* 
accounting  functions. 


which  performs 
particulsr,  it 
and  al I ocates 
and  performs 
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Interprocess  communication  (ipcl 


f ; ; 

l i . 


Interprocess  communication  is  a facility  which  allows  one 
process  to  communicate  with  another  in  a controlled  manner. 
Both  the  sending  and  receiving  processes  must  adhere  to  a 
specified  protocol. 


This  term  is  used  frequently  as  an  abbreviation  for  the 
•evel/category  combination  which  describes  a clearance  or  a 
classification.  Thus  the  “level”  of  a process  Is  the 
clearance  of  the  process  ana  the  “level"  of  a segment  is  the 
classification  of  the  segment. 


Multi-Level  Security  Mode  (see  also  Two-Level  Security  Mode) 

A mode  of  operating  under  an  operating  system  (supervisor  or 
executive  program)  which  provlces  a capability  permitting 
various  levels  and  categories  cr  compartments  of  material  to 
be  concurrently  stored  and  processed  in  an  AOP  System.  In  a 
remotely  accessed  resource-shar ing  system,  the  material  can 
be  selectively  accessed  ano  manipulated  -from  termirals  by 
personnel  having  different  security  clearances  and  access 
approvals.  This  mooe  of  operation  can  accommodate  the 
concurrent  processing  and  storage  of  (a)  two  or  more  levels 
of  classified  data,  or  (b)  one  or  more  levels  of  classified 
data  with  unclassified  data  cepending  upon  the  constraints 
placed  on  the  systems  by  the  Designated  Approving  Authority. 


Operating  System  (0/S) 

An  integrated  collection  of  service  routines  for  supervlsirg 
the  sequencing  and  processing  of  programs  by  a computer. 
Operating  systems  control  the  allocation  of  resources  to 
users  and  their  programs  and  play  a central  role  in  assuring 
the  secure  operation  of  a computer  system.  Operating 
systems  may  perform  debugging.  input -output  * accounting, 
resource  allocation,  compilation*  storage  assignment  tasks, 
ana  other  system  related  functions  (Synonymous  with  Monitor. 
Executive.  Control  Program,  ano  Supervisor). 


per sonid 

The  registered  name  of  someone  who  Is  authorized  to  use  the 
system.  It  is  usually  constructed  from  the  last  rame 
(Surname)  of  the  person. 
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process 


A process  is  the  active  agent  of  the  user  on  Multics  and  (in 
the  security  system)  has  a clearance  Mhich  may  not  exceed 
V the  user's  clearance.  The  lifetime  of  a process  normally 

: corresponds  to  a user's  terminal  session  anc  is  described 

I internally  by  an  address  space  and  a point  of  execution. 

Both  the  address  space  and  the  execution  point  are  dynamic 
over  the  life  of  the  process. 


prolectid 

The  registered  name  of  a project  Mhich  has  an  account  on  the 
system. 


Remotely  Accessed  Resource-Sharing  Computer  System 


A computer  system  which  includes  one  or 
processing  units*  peripheral  devices,  remote 
communications  equipment  or  i n terconnect i on 
allocates  its  resources  to  one  or  more  users* 
be  entered  from  terminals  located  outside 
computer  facility. 


more  central 
terminals*  and 
I inks*  wh icn 
and  which  can 
the  central 


segment 


A segment  is  a logical  unit  of  storage  on  Multics.  it 
roughly  corresoonds  to  a file  stored  on  a disk  oack  and 
accessible  to  a user.  The  segment  is  the  smallest  element 
of  supervisor  access  control  in  the  Multics  storage  system. 
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Two-Level  Security  Mode 

A mode  of  operating  a computer  system  which  provides  a 
capability  permitting  Top  Secret  and  Secret  data  to  be 
concurrently  stored  and  processed  in  an  AOP  Svstem.  This 
mode  is  more  restricted  th3n  the  multi-level  security  mooe 
in  that  only  Top  Secret  ano  Secret  cleared  users  will  be 
permitted  to  access  the  system.  No  unsecure  terminals  will 
be  connected  to  the  system.  Software*  hardware* 
administrative*  and  physical  controls  will  provide  the 
safeguards  to  assure  th a integrity  of  the  classified  oata 
processed. 
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user 


An  instance  of  a person  logged  irto  the  system  on  a project 
A user  is  identified  by  a userid* 


userid 

A table  entry  Mhich  would  describe  a user  (e*e.  an  access 
control  list  entry)*  A userid  consists  of 
••personid.prol  ectid.  tag*"  where  tag  is  normally  “a"  for  an 
interactive  user,  "a*  for  an  absentee  user,  and  for 
certain  system  daemons.  The  userid  is  also  called  the 
“principal  identifier**  or  ••group^ld”  of  the  user. 
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3.2  APPLICATION  OF  SECURITY  CONTROLS  TO  MULTICS 


Each  person  registered  on  Huitics  is  Known  to  the  system  by 
his  name  (personld)  and  has  a password  to  authenticate  his 
identity.  The  aut hen t ic a t lor  data  for  a personld  must 
Include  the  person's  system-recognized  clearance. 

Each  user  of  Huitics.  as  identified  by  his  userid 
(person-pro| ec t combination).  is  associated  with  a Huitics 
process.  Each  Huitics  process  must  have  a clearance  which 
is  equal  to  or  less  than  the  clearance  of  the  person 
associated  with  the  process  ano  must  remain  constant  for  the 
life  of  the  process. 

Access  control  is  generally  described  as  a sub|ect 
attempting  to  access  an  object  through  an  intervening 
reference  monitor.  The  reference  monitor  checks*  each  and 
every  time  a subject  attempts  to  access  an  object,  to  see  if 
the  subject  has  the  proper  authorization  to  perform  the 
desired  operation  (e.g*  reac.  write*  execute.  append, 
modify,  delete).  In  Huitics.  a process  is  the  only  subject 
which  can  make  a reference  to  any  object.  The  set  of 
ob|ects  are  segments,  directories,  branches,  I/O  chanrels 
ana  interprocess  communication  messages.  Each  object  must 
have  a classification  level  ano  category  set  associated  with 
it. 

In  Huitics,  tne  reference  monitor  which  vaiioates  each 
reference  to  an  object  is  the  "ring  0"  supervisor  in 
conjunction  with  processor  hardware  protection  mechanisms. 
Within  the  protection  ring  scheme  supported  by  the  Honeywell 
6180  processor,  ring  o is  the  most  privileged  ana  most 
protected  ring  of  operation.  All  access  control  decisiors 
are  made  within  ring  0.  Each  time  a process  attempts  to 
gain  access  to  an  object,  the  clearance  of  the  process  is 
compared  with  the  classification  of  the  object  and  access  is 
either  granted  or  denied  in  accordance  with  rules  designed 
to  emulate  the  military  security  system.  In  aaditlor  to 
classification,  certain  objects  such  as  segments  and 
directories  have  an  associated  access  control  list  which 
specifies  persons  having  need  to  know  author i lati on  as  in 
the  military  security  system. 
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When  the  classification  of  two  objects  Is  compared*  four 
relationships  are  possible! 


less  than 
equal 

greater  than 
iso  I ated 

The  classification  of  object  i is  considered  “less  than"  the 
classification  of  object  2 1 f > 

1.  The  level  of  object  i is  numerically  less  than  or 
equal  to  the  level  of  object  2*  and 

2.  The  category  set  of  object  l is  a subset  of  the 
category  set  of  object  2?  and 

3.  The  classification  of  object  l is  not  equal  to  the 
classification  of  object  2* 

The  classifications  of  two  objects  are  considered  “equal” 
lf« 

1.  The  levels  are  numerically  equal!  and 


2.  The  category  sets  are  iaentical. 

The  classification  of  object  i is  considered  "greater  than" 
the  classification  of  object  2 i fi 

1.  The  level  of  object  i is  numerically  greater  than 
or  equal  to  the  level  of  oblect  2!  and 

2.  The  category  set  of  object  2 is  a subset  of  the 
category  set  of  object  1!  and 

3.  The  classification  of  oblect  i is  not  equal  to  the 
classification  of  object  2. 

The  classifications  of  two  objects  are  considered  "isolated" 
if  the  category  sets  are  isolated. 

The  “minimum"  of  several  classifications  is  defined  as! 

1.  The  numerical  minimum  of  the  levels;  and 

2.  The  Intersection  of  the  category  sets. 

In  order  for  a person  to  access  information*  the  eilitary 
security  system  requires  that  the  clearance  of  the  person  be 
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greater  than  or  equal  to  the  classification  of  the 
information.  A sufficient  condition  for  satisfying  this 
requirement  within  the  computer  system  environment  is  the 
enforcement  of  the  following  two  rulesi 

1.  A process  having  clearance  fl  may  not  "reed  up»"  i.e. 
read  an  object  having  a classification  greater  than  o. 

2.  A process  having  clearance  fi  may  not  "write  down."  i.e. 
write  an  ob|ect  having  a classification  less  than  q. 

with  these  two  rules  enforced*  it  is  impossible  for  any 
process  to  extract  information  from  an  object  of  higher 
classification  or  to  transfer  information  from  an  object  of 
higher  classification  to  an  object  of  lower  classification. 
Hence*  no  compromise  of  classified  information  can  occur. 
This  principle  is  known  as  the  "fixed  level  property."  A 
further  restriction  is  also  desirable  which  forbids  a 
process  to  write  in  an  object  of  higher  classification 
whenever  writing  can  be  used  to  destroy  information.  In 
order  to  provide  some  protection  against  sabotage*  "write 
up"  operations  must  not  be  permitted  for  such  objects  3S 
segments*  directories,  and  branches. 

It  is  Important  to  recognize  that  the  rules  described  above 
represent  a sufficient*  but  not  a necessary  conditior  for 
achieving  security.  Although  the  fixed  level  property 
restrictions  will  be  strictly  enforced  for  all  user 
processes,  they  will,  in  certain  circumstances,  be  aooiled 
Interpretive! y for  trusted  system  processes.  In  no 
circumstances*  however,  will  security  be  violated,  because 
trusted  system  processes  mus  t operate  correctly. 

The  individual  user  must  be  able  to  specify  which  users 
Should  have  "need  to  know"  for  a given  segment  or  directory 
by  use  of  the  Access  Control  List.  The  mode  of  access  (e.c. 
read,  write)  allowed  to  a process  by  the  current  Multlcs 
Access  Control  List  must  be  further  restricted  to  ensure 
compliance  with  the  fixed  level  property  rules.  In  other 
words*  the  fixed  level  property  rules  must  take  precedence 
over  the  Access  Control  List. 

Information  transmitted  between  hardware  modules  must  pe 
carefully  controlled  by  the  system  and  no  user  should  be 
able  to  directly  affect  the  action  of  an  active  module 
(except  for  the  CPU).  Furthermore*  no  user  process  should 
be  able  to  execute  any  programs  which  would  perform  external 
I/O  to  any  device  other  than  his  terminal. 

The  system  can  oe  logically  diviced  into  two  env ircrments l 
internal  and  external.  The  internal  environment  is  totally 
controlled  by  the  system.  This  includes!  processors* 
memory*  disk  drives,  I/O  mu  1 1 i o I exers » bulk  store. 
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The  external  environment  can  be  directly  influencec  by  the 
actions  of  a process.  This  environment  includes! 
terminals*  line  printers*  card  readers*  card  punches* 
non-system  tape  drives*  and  other  devices  In  the  I/O  class 
not  used  for  system  functions. 

To  provide  a “secure"  pipeline  between  the  internal  and 
external  environments*  a trusted  process  must  perform  the 
actual  information  transfer  on  behalf  of  the  user.  This 
will  further  ensure  that  failures  or  "software  buds*'  will 
not  be  exploited  by  a user.  The  terminal  must  be  the  only 
exception  to  this  rule  and  this  exception  is  only  made  for 
the  sake  of  efficiency. 

Whenever  possiDle*  new  or  mocifled  operator  interfaces 
supplied  with  the  security  control  features  will  be  designed 
to  provide  extra  aids  or  simplicity  in  structure  to  help  the 
operator  avoid  mistakes  which  could  become  security 
viol  at  ions. 


Security  and  administrative  functions  should  be  separatee  to 
ensure  that  the  System  Administrator  will  not  make 
security-related  decisions  and  to  avoid  burdening  the 
Security  Officer  with  purely  acm in istrat lve  decisions. 

The  security  controls  must  be  designed  so  thatt  the  system 
is  easy  to  use?  the  users  are  encouraged  to  properly 
classify  data  (rather  than  over-c I ass i t y ) ; the  least 
possible  amount  of  current  Multlcs  functionality  is 
sacrificed;  and  the  current  user  interface  is  mairtalneo 
wherever  possible. 


All  high-level  security-related  actions  performed  within  the 
system  should  be  audited  to  ensure  user  responsibility  ara 
to  provide  early  warning  of  any  subversion  attempts*  misuse 
of  the  security  controls*  or  actions  which  could  lead  to 
compromise. 


All  revisions  to  the  system  must  be  carefully 
minimize  the  possibility  of  "bug  fixes"  or  new 
causing  the  system  to  behave  incorrectly,  especia 
as  security  is  concerned. 


checkeo  to 
"features" 
ty  insofar 
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3.3  PROCESS  CLEARANCE  ASSIGNMENT 


3.3.1  Requirements 

A Hultics  process  is  unlouely  essoclated  mith  a person  Mho 
Is  registered  to  use  the  system  and  a project  to  Mhlch  that 
person  may  charge  his  system  expenses. 

Mhen  a process  Is  created  for  a user,  a clearance  Mill  be 
established  for  the  process.  This  clearance  must  not  be 
changeable  by  request  for  the  life  of  the  process.  It  is 
the  process  clearance  mhlch  Mill  be  used  to  determine  a 
user's  author  1 zati on  to  access  classified  Information  in  the 
system. 

To  provide  a degree  of  flexibility  and  aomlnlstrati v« 
control,  the  clearances  of  several  entitles  must  be  stored 
on  tne  system. 

The  data  associated  Mith  a oersonld  (the  system  unique 
identification  for  the  person)  must  contain  the  clearance  of 
the  person.  Similar  clearance  data  must  be  associated  mltn 
each  orojectid.  In  addition,  the  data  mhlch  describes  the 
limitations  of  a person  on  a given  project  must  have 
clearance  data. 

The  clearance  to  be  assigned  to  a process  must  be  determined 
as  f oi loms* 

1.  No  process  mill  be  createc  for  a given  userid.  l.e.  a 
given  person  on  a given  project.  mith  a higher 
clearance  than  the  minimum  of  the  person's  clearance, 
the  project's  clearance*  and  the  person’s  clearance 
Mlthin  the  project. 

2.  No  user  should  be  able  to  create  a process  Mith  a 
higher  clearance  than  the  maximum  clearance  of  his 
terminal . 

3.  A user  must  be  able  to  reaucst  a process  mith  a lomer 
clearance  than  the  iriniaua  of  his  userlo  and  terminal 
c I earance. 

4.  A user  must  be  able  to  specify  a oefault  login 
clearance  (no  higher  than  his  oersonld  clearance). 
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Only  the  System  Security  Officer  (SSO)  must  be  able  to 
assign  clearances  for  a personld  or  a projectio.  If  the  SSO 
lowers  the  clearance  of  a oersortid*  the  user’s  process  must 
be  forceably  terminated  If  he  has  an  active  process  with  a 
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greater 
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beginning  and  normal  termination  of  the  process.  In  this 
way*  the  user  is  made  explicitly  aware  of  his  level  of 
operation.  Hence,  mistakes  such  as  Placing  Top  Secret 
information  in  a Secret  file  are  unlikely  to  occur,  ana  if 
they  do  occur,  are  likely  to  be  cetected  before  any  harm  can 
resu 1 1 . 

By  use  of  a command,  each  user  should  be  able  to  request 
that  the  clearance  of  his  current  process  be  tyoed  on  his 
termina I . 


The  names  associated  with  a "level**  should  be  set  by  the 
insta I I at  ion. 
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The  system  control  process  uses  three  tables  to  verify  that 
a user  should  be  logged  in. 

1.  The  Person  Name  Table  (PNTJ  contains  an  entry  for  each 
personld  on  the  system. 

2.  The  System  Administration  Table  CSAT)  contains  an  entry 
for  each  orojectid  on  the  System. 

3.  The  Project  Definition  Table  for  the  users  project 
(Prol.pdt)  contains  an  entry  for  each  personld  allowed 
to  used  the  project.  There  is  one  project  oefinitlon 
table  for  eacn  orojectid. 

Each  of  these  tables  will  be  modified  to  hold  clearance 
level  and  category  set  data  for  each  entry.  The  system 
control  process  will  check  this  clearance  date  to  deteririre 
the  maximum  clearance  for  a userio. 


A new  table,  called  the  Peripheral  Control  Table  IPCTJ,  wilt 
be  used  by  the  system  control  process  to  check  the  maximum 
clearance  of  tne  terminal  being  used  by  a person  attempting 
♦o  log  in.  Since  terminals  will  be  "hard  wired”  to  t^e 
system  at  AFOSC,  each  terminal  can  be  uniouely  identlfleo  by 


an  associated  channel  number, 
may  be  cr ypto-dl a I -up  terminals, 
crypto  units  will  provide 
identification.  As  an  extra 


In  the  general  case,  there 
However,  in  that  case,  tre 
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received  from  a terminal  mill  be  compares  against  its 
“registered**  answerback  code.  This  answerback  test  will  be 
useful  in  detecting  mistakes?  as  well  as  malicious 
tampering?  involving  communications  lines  and  terminals. 

At  login  time?  the  user  will  be  given  a process  with  a 
clearance  no  higher  than  the  minimum  of  the  clearances  from 
the  PNT  ? SAT?  Prol.pdt?  ano  the  PCT . The  default  login 
clearance  for  each  user  will  initially  be  the  lowest 
possible  clearance?  l.e.  unclassified.  A new  login  option 
will  be  suoDtled  to  oermlt  a user  to  change  this  default. 
Also?  another  new  login  option  will  be  provided  which  allows 
the  user  to  specify  a particular  clearance  for  a given 
login. 

An  attempted  login  may  be  reiected  for  the  following 
reasons i 

1.  illegal  login  word 

2.  incorrect  parsonic  or  projectid 

3.  incorrect  password 

4.  Incorrect  level  option 

5.  unrecognized  login  option 

These  rejected  login  attempts  will  be  recorded  for  audit 
purposes.  In  addition?  it  a user  attempts  to  use  e terminal 
with  a maximum  clearance  greater  than  the  personld  clearance 
from  the  PNT?  a message  will  be  sent  to  the  operator?  since 
this  will  indicate  a breach  of  ohyslcal  security.  The 
clearance  of  the  process  will  be  stored  in  the  process 
initialization  table  (pit)  and  in  the  ring  C process  data 
segment  (pds)  of  the  process  to  ensure  tnat  it  is 
unforgeable  for  the  life  of  the  process. 

The  Project  Administrator  will  be  able  to  specify  for  a user 
on  his  project  a lower  maximum  clearance  than  authorlzeo  in 
the  PNT  ano  SAT?  if  this  ability  is  granted  by  the  SSO. 

Person  and  orojact  responsibilities  of  the  System 
Administrator  will  remain  the  same  as  on  the  current  Multlcs 
systems.  When  a new  user  or  project  is  added  to  the  system, 
the  maximum  clearance  will  be  set  to  unclassified.  Orly  the 
SSO  will  have  access  to  the  coemands  to  update  clearances 
in  the  PNT?  SAT  ana  PCT. 

Anonymous  users  should  not  normally  be  permitted  on  the 
system  since  password  authentication  is  not  always  reaulred 
for  them.  Where  passwords  are  required  for  anonymous  users? 
these  passwords  are  controlled  by  protect  administrators 
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rather  than  the  SA  or  the  SSO.  Iff  at  any  tieef  anonymous 
users  are  permitted  on  the  system*  they  Mill  alMays  be  given 
unclassified  processes* 


Absentee  processes  Mill  be  created  at  the  level  of  the 
requesting  process  unless  an  option  is  specified.  A user 
Mill  not  be  able  to  create  an  absentee  process  Mith  a 
clearance  Mhich  is  lower  than  his  current  process  clearance* 
since  the  passing  of  arguments  to  the  absentee  process  Mould 
constitute  a write-down  operation. 

A new_proc  option  will  be  added  to  allow  a user  to 
uograde/downgrade  his  level  of  operation.  When  no  option  is 
specified*  the  default  level  for  the  new  process  will  be  the 
current  level.  (The  same  will  be  true  for  abnormal 
termination  of  a process). 

The  system  process_o verseer_  procedure  will  identify  the 
**level“  of  a process  created  for  a user  by  printing  the 
“level”  name  on  his  terminal.  (This  cannot  oe  oefested.) 
The  same  message  will  be  printed  by  terminate_process_  for 
normal  process  termination. 

Installation  parameters  will  be  used  to  store  the  character 
strings  used  to  identify  each  classification  level  and 
category.  The  system  assumes  that  the  names  used  for  levels 
and  categories  are  unc I ass  if iec. 

Each  user  will  be  able  to  execute  a command  which  will  print 
the  "level”  of  his  process  on  his  terminal  based  on  the  oata 
in  the  “pit." 


3.3.3  Potential  Security  Problems 

The  following  areas  will  become  security 
the  non-ma I i c ious  user  assumption  of 
violated. 


prob I ems 
Section 


on  I y 
3.1.4 


The  ability  for  a user  to  enter  an  absentee  request  of  an 
equal  or  higher  "level"  than  his  orocess  clearance  Is  one 
way  for  a Trojan  Horse  to  gain  control  of  a user's  access 
permissions  without  the  user  noticing  excessive  processor 
usage  or  real  time  delays  within  his  current  process.  It 
this  happens*  a need  to  Knew  violation  or  sabotage  can  occur 
very  easily*  but  the  only  means  for  compromise  woulo  be 
through  the  quota  path  on  directories  which  has  a very  low 
transmission  rate.  (See  Section  3*7.4) 

By  providing  a means  for  a user  to  change  his  “level”  of 
operation  through  program  control  (new_proc  with  level 
option)*  a Trojan  Horse  coulo  set  itself  up  as  the  program 
to  be  called  when  a user  attempts  to  change  to  a new  “level” 
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process*  An  elaborate  Trojan  Horse  could  totally 
system  action  for  new_proc  to  fool  the  user  into  t 
is  operating  at  a higher  level*  Now  if  the  user  a 
input  classified  data*  the  Troian  Horse  coula*  by 
the  entire  user  interface*  cause  the  user  t 
classified  data  into  a segment  with  a lower  class 
This  problem  can  be  solved  by  only  allowing 
"new_proc"  to  the  same  or  lower  “level." 
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In  a similar  manner*  a user  may  write  hi 
command  to  fool  the  next  user  of  the  ter 
he  is  talking  to  the  system  Instead  of 


process*  This  could 
password  of  another 
to  know  violations, 
environment  simulat 
The  solution  to  this 
be  powerea  off  by 
(This  can  be  handled 
site  manager.) 


allow  a ma I ic ious  u 
user,  thus  permitti 
(See  Section  3*4. i* 
on  described  above 
problem  is  to  requl 
each  user  before 
several  ways.  The 


s own  "logout  -hoi  a" 
mlnal  into  thinking 
the  previous  user's 
ser  to  capture  the 
ng  sabotage  and  need 
I Also*  tht  user 
could  be  useo  here, 
re  the  terminal  to 
attempting  to  login, 
choice  is  up  to  the 


Solutions  exist  to  all  of  the  above  potential  oroblems. 
However*  given  the  low  expectation  of  occurrence  of  these 
problems*  the  required  sacrifices  in  user  convenience  were 
felt  to  be  unwarranted  within  the  assumed  benign 
environment. 


1 


29 


3.4  PASSMORO  CONTROL 


3.4.1  Description 

The  Multics  access  control  mechanism  depends  on  several 
important  factors.  First  ana  foremost  is  the  notion  of  an 
unforgeable  “user  name"  which  identifies  the  access  rights 
of  a Multics  process*  the  entity  which  performs  all  tasks  on 
behalf  of  the  human  user.  A Multics  “user  name"  is  called  a 
principal  identifier,  and  consists  of  three  comconertst 
Person,  Project,  and  Tag.  The  Person  component  uniquely 
identifies  a registered  user  of  Multics.  The  Project 
component  identifies  a registered  project,  ana  Tag  is 
presently  derived  from  the  type  of  process  (l.e. 
interactive,  absentee,  or  consoleless  daemon). 

In  order  for  Multics  to  successfully  enforce  access 
controls,  it  must  be  possible  tc  uniquely  and  positively 
identify  each  user  at  login.  This  is  presently  accomplished 
by  assigning  each  registered  person  his  own  password,  anc  et 
each  login,  requesting  his  password  for  verification 
purposes.  If  the  password  stored  by  Multics  matctes  the 
password  given  by  the  user,  Multics  assumes  the  user  is 
valid,  and  creates  a process  with  the  principal  identifier 
(userid)  of  the  user.  If,  after  giving  the  user  several 
chances  (to  allow  for  typing  mistakes),  a correct  password 
has  not  been  received,  Multics  refuses  the  login. 

Clearly,  the  password  is  a vital  part  of  fhe  access  control 
mechanism,  ana  as  such,  must  be  carefully  protected  by  both 
the  user  and  the  system.  If  a person  could  guess  (by 
whatever  means)  another  user's  password,  that  person  would 
himself  be  able  to  log  in  as  the  other  user.  It  shoulc  be 
noted,  however,  that  due  to  ohysical  security  controls  at 
AFOSC,  the  compromise  of  a password  cannot  result  in  the 
compromise  of  classified  lrf ormatior..  A person  who  learns 
another  person's  passworo  will  not  be  able  to  log  in  with 
the  same  clearance  as  the  owner  of  the  passworo  unless  he, 
himself,  has  an  equal  or  higher  clearance  which  affords  him 
access  to  a terminal  of  equal  or  higher  c I assi f icatior. 
Therefore,  password  compromise  can,  at  worst,  result  in 
sabotage  or  need  to  knew  violations. 


30 


3.4.2  Requirements 


The  present  "norh  factor**  needed  to  guess  a person’s 
password  Is  not  high  enough,  due  to  the  ability  of  a user  to 
choose  his  own  password*  Therefore,  it  is  a requirement 
that  the  system  assign  passworcs*  (The  passwords  could  have 
been  distributed  manually,  but  that  was  felt  to  be  too 
burdensome  for  the  system  administrator.! 

To  provide  the  ability  to  control  the  "age**  of  a password 
(how  long  it  has  been  in  use  by  a user),  it  is  a requirement 
that  the  system  be  able  to  force  a user  tc  change  his 
password  at  ore-determined  intervals. 

To  be  able  to  recover  from  a password  breach,  it  is  a 
requirement  that  the  System  Security  Officer  be  able  to 
force  some  or  all  users  to  change  their  passwords. 


3.4.3  Oesign  Considerations 

Since  all  users  must  go  through  the  login  ritual,  every 
attempt  will  be  made  to  "human  engineer"  this  area  of  the 
system.  The  passwords  generated  by  the  system  will  be 
designed  to  be  pronounceable  and  therefore,  easy  to 
remember. 


3.4.4  Chosen  Approach 

After  the  identity  of  the  user  has  been  authentl catec  by  the 
login  procedure,  the  system  will  warn  the  user  if  it  is  time 
to  change  his  password.  To  force  the  user  to  change  his 
passwora  within  an  i ns ta I I at i or- parameter  grace  time,  the 
user  will  be  locKec  out  if  he  exceeds  the  grace  time.  To 
properly  handle  persons  who  logir  infrequently,  the  grace 
"time"  will  actually  be  implemented  as  a grace  number  of 
logins. 

The  system  generated  passwords  will  be  baseo  on  English 
digraph  frequencies  since  such  wcrds  are  more  pronounceable, 
and  thus  more  easily  remembered,  than  ranoom  strings  of 
char ac ters. 

Since  passwords  must  be  treated  as  classified  information, 
the  system  will  prefix  the  printing  of  a now  password  with 
the  label  "confidential.** 

To  ensure  that  the  user  understands  the  new  password  and 
that  it  was  printed  correctly,  the  user  will  be  reouireo  to 
echo  it  at  login  time. 
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The  SSO  Mill  be  able  to  set  the  interval  at  Mhieh  users  must 
change  their  passwords. 
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The  SSO  Mill  be  able  to  force 
Incorrect  login  attempts  Mill 


e user  to  change  his  passworo. 
be  audited  (see  Section  3*161. 
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3*4.5  Examples 


1* 

2 

3* 

4 

5 

6* 

7 


login  Whitmore  -charge_pass Mord 
Password l 

Confidential  t New  password  is  “abcodo.1 
New  PassMordi 

Passmore  changed. 


Lines  marked  Mith  *****  are  typed  in  by  the  user, 
terminal  does  not  print  passwords  typed  by  the  user. 


The 


In  the  first  example.  Whitmore  requests  that  his  passMoro  oe 
changed.  The  system  requests  his  current  oassmord  and 
assigns  him  a new  one.  The  user  is  requested  to  enter  hJs 
new  password  for  verification.  If  both  passwords  were  typed 
correctly,  he  will  be  logged  in  and  his  password  will  be 
changed  within  the  system.  If  either  oassworo  was 
incorrect,  the  entire  login  would  be  incorrect  ana  the  user 
would  have  to  try  again. 


1*  login  Whitmore 

2 Password* 

3* 

4 You  must  change  your  password  within  3 logins 


In  the 
password 
he  fails 
user  may 
his  pass 


second  example,  Whitmcre  is  notified  that  his 
must  be  changed  within  the  next  three  loqlns.  If 
to  change  his  passworc,  he  will  be  locked  out.  The 
login,  even  if  he  has  been  locked  out,  by  changing 
word. 
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3.5  INFORMATION  CHANNELS  BETWEEN  PROCESSES 
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The  fixed  level  property  rules  defined  In  Section  3.2  ere 
designed  to  restrict  the  passing  of  information  between 
processes.  These  restrictions  must  be  applied  to  ell 
Information  channels,  l.e.  to  all  mechanisms  •uU'lr  tre 
system  which  enable  processes  to  exchange  information. 
Certain  mechanisms  such  as  stared  segments  and  tre 
Interprocess  communication  facility  are  deliberately 
provideo  to  serve  as  information  channels.  Otter  mechanisms 
such  as  segment  names  ana  access  control  lists  are  IMeroeJ 
to  serve  different  purposes*  but  could  be  misused  as 
information  channels  by  processes  attempting  to  compromise 
information.  Hence*  all  irfcrmatlon  channels  must  oe 
Identified  and*  where  necessary*  additional  access  checking 
must  be  provided  in  oroer  to  enforce  the  fixed  level 
property  rules. 


3.5.1  Segment  Sharing 

A shared  segment  is  the  most  natural  channel  for  two 
processes  to  exchange  information.  For  a process  with  a 
clearance  P»  the  system  will  systematically  remove  the 
"write"  permission  on  any  segment  whose  classification  is 
lower  than  P,  and  all  permissions  on  any  segment  whose 
classification  is  higher  than  P.  It  is  therefore  impossible 
for  a process  to  "write  down"  or  to  "read  up." 

More  detail  can  be  found  in  section  3.6  - "Access  to 

Segments ." 


3*5.2  Directories 

Directories  are  another  channel  through  which  processes  can 
exchange  information.  Fach  data  item  contained  in  a 
directory  is  assigned  a specific  classification  (as 
described  in  Section  3.71*  Ring  3 primitives  in  charge  of 
manipulating  directories  will  provide  additional  checking  by 
which  they  will  systematically  refuse  to  perform  a request 
if  it  would  result  in  a "write  dcwn"  or  a "read  up." 
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Unfortunately*  however*  a number  of  Jirectory  Items  such  as 
quota  used*  date-time  modified*  and  date-time  used  are 
changed  not  by  explicit  request*  but  rather  as  a side-effect 
of  some  action  performed  outside  the  directory.  For 
example*  the  quota  usee  count  stored  in  a directory  can  be 
increased  by  growing  the  size  of  an  inferior  segment. 
Information  channels  of  this  type  present  rather  unusual 
problems.  Solutions  to  these  problems  as  well  as  other 
details  of  directory  access  control  are  discussed  in  “3.7 
Access  to  Director i es ." 


3.5.3  Interprocess  Communication 

Using  the  Interprocess  Communication  (IPC)  facility,  a 
process  can  sand  a 72-blt  message  to  another  process.  The 
IPC  facility  will  provide  additional  checking  by  which  it 
will  systematically  refuse  to  send  a message  that  would 
result  in  a “send  down.”  “Seno  uo“  will  be  permitted  for 
IPC  since  this  is  not  a means  of  sabotage.  The  enforcement 
of  the  security  will  be  done  in  ring  0. 


3.5.4  Message  Segments 

In  the  current  Mul tics  System,  message  segments  are  ring  ore 
segments,  manipulated  by  a rirg  one  module  called  the 
Message  Segment  Facility  (msf).  The  implementation  of  the 
ms f is  such  that  a process  neeos  the  “read”  ana  the  "write” 
capabilities  in  ring  one  on  a message  segment  in  order  to  be 
able  to  out  a message  in  it  or  to  extract  a message  from  it. 
It  follows  that,  if  the  msf  is  used  wlthir  the  security 
controls,  communication  between  processes  through  message 
segments  will  be  restricted  to  processes  of  idenficial 
clearance.  Tnls  restriction  hes  been  accepted. 

As  far  as  security  is  cor.cernec,  message  segments  will  be 
treated  tne  same  as  any  other  segment  by  the  rinq  Q 
supervisor  and  one  can  repeat  what  was  said  for  segments  in 
general!  no  read  up  or  write  conn  on  a message  segment  will 
be  permitted  in  a user  process.  however  some  system 
processes,  in  same  special  cases  and  in  a controlled  manner, 
will  nave  to  byoass  tne  fixed  level  prooerty  restrictions  on 
message  segments.  However,  in  no  circumstances  will 
security  be  violated. 

In  the  current  Multics  system,  all  user  processes  that 
request  a service  from  a system  process  send  their  request 
through  a message  segment.  It  fellows  that,  wherever  the 
current  system  uses  one  message  segment  to  Queue  user 
requests  for  a system  process,  it  will  be  necessary  to 
provide  one  message  segment  for  each  existing 
c I ass i f leaf  ion. 
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An  alternative  approach  Mould  have  allowed  security  rules  to 
be  enforced  in  ring  one  rather  than  ring  0.  In  this  scheme, 
ring  0 would  jrant  read  ano  write  access  for  message 
segments  to  processes  of  all  clearances.  Each  indivicual 
message  stored  in  a Message  segment  would  be  "classified"  by 
the  msf  at  the  clearance  level  of  the  sending  crocess.  The 
ms f would  only  permit  extraction  of  a message  by  a process 
having  a clearance  higher  or  eoual  to  the  classification  of 
the  message.  However,  this  would  bring  the  msf  clus  all 
other  ring  one  procedures  within  tne  security  perimeter, 
thereby  making  the  task  of  certification  more  difficult. 


3.5.5  Summary 

It  is  important  to  understand  that  of  the  severe! 
information  channels  described  above,  shared  segments  are 
the  only  channel  through  which  classified  information  would 
routinely  be  stored  and  passed.  IPC  messages  and  directory 
items  such  as  segment  names  or  access  control  lists  would 
not  normally  be  used  to  transmit  or  store  classified  data. 
(All  segment  names  are  assumed  to  be  unclassified  so  that 
they  may  appear  in  unclassified  accountability  forms  for 
printed  output.  See  Section  3. id. I Hence,  from  a practical 
standpoint,  the  assigning  of  correct  classifications  to 
segments  by  users  and  the  addition  of  fixed  level  property 
access  checking  for  segments  is  sufficient  to  prevent  a 
single  malicious  user  from  directly  compromising  classified 
informat  ion. 

The  other  information  channels  do  not  become  a serious 
problem  until  one  considers  the  possibility  of  two  (or  morel 
processes  cooperating  in  an  effort  to  compromise 
information.  This  cooperatior  could  take  one  of  two  forms. 
First,  two  malicious  users  might  directly  conspire  to 
compromise  in f arm a t i on , Second,  a non ma I ic 1 ous  user  might 
unknowingly  employ  a Trojan  Horse  program  supplied  by  a 
malicious  user.  (See  Section  1.2. 2. 2. I The  case  of  two 
users  conspiring  to  compromise  information  is  actually  more 
of  a "people-  problem  than  a computer  system  problem.  Even 
if  no  effort  were  maoe  to  secure  those  Information  channels 
not  normally  used  to  store  or  transmit  classified  data, 
conspiring  users  would  probably  still  find  it  easier  to  pass 
information  outsiae  the  system.  Therefore,  the  Troian  Horse 
attack  is  really  the  only  term  of  attack  for  wt  ich 
information  channels  other  than  segments  are  essential. 


The  design  presented  in  this  report  is  directed  to 
eliminating  all  read-up  ano  write-down  information  charnels. 
The  elimination  of  all  krown  read-up  channels  prohibits  a 
malicious  user  from  directly  accessing  classified 
information  which  he  is  not  legitimately  cleared  to  see. 
Hence,  a malicious  user  must  resort  to  "setting  a trap," 
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i.e.  he  must  create  3 Troian  Horse  program  with  the  hope 
that  an  unsuspecting  user  tawing  a higher  clearance  will 
call  it.  Although  a general  solution  to  the  Troian  Horse 
problem  is  beyono  the  scope  of  This  design,  the  elimination 
of  write-down  channels  can  considerably  reduce  the  threat 
represented  by  the  Trojan  Horse  form  of  attach.  A 
write-down  channel  is  the  only  means  by  which  a Trojan  Horse 
program  can  actually  compromise  information.  Therefore*  the 
elimination  of  ail  write-down  channels  can  effectively 
prevent  compromise*  although  sabotage  and  neeo  to  Knew 
violations  would  still  be  possible.  Hith  one  exception*  all 
explicit  write-down  channels  within  the  Multics  system  ra«e 
been  eliminated  in  this  aesicn.  The  quota  used  charnel  is 
the  single  exception.  Not  only  aoes  this  channel  have  a 
very  low  transfer  rate*  but  also,  any  significant  use  of 
this  channel  can  be  easily  detected  through  auolting.  (See 
Section  3*7.3  for  details.) 
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i.fc  ACCESS  TO  SEGMENTS 


3.6.1  Requirements 

Every  segment  must  rsve  a classification  deflrea  by  a level 
ana  category  set.  This  classification  applies  to  all  oaf  3 
contained  within  the  sequent. 

For  each  segment  there  ui.st  exist  a list  of  censors  raving 
need  to  Know  access  to  the  contorts  of  the  segment. 

The  sharing  of  segments  among  processes  must  be  control  lea 
so  as  not  to  violate  the  fixed  level  property  rules. 

3.6.2  Oesign 
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Tne  c I ass i f ic a t i on , i.e.  level  and  category  set,  of  a 
segment  will  be  permanently  recorded  in  its  branch.  tor 
reasons  explained  in  Sectior  3.7.  the  classification  of  a 
segment  must  equal  the  classification  of  Its  oarent 
directory.  This  implies  that  the  classification  of  a 
segment  will  always  eoual  the  clearance  of  the  orocess  which 
created  it,  since  a process  can  cn I y aooend  a branch  to  3 
directory  if  its  clearance  equals  the  directory 
classification. 
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As  is  already  tne  case  ir  Mu  I tics,  an  access  control  list 
(ACL)  will  be  associated  «itr  every  oranch.  Each  ACL  entry 
contains  a userid  and  access  moae.  The  access  moae 
describes  tne  types  of  eccess  (e.g.  read,  execute,  write! 
permitted  the  associated  user.  Hence,  the  ACL  will  be  used 
to  control  need  to  Know  access  to  a segment. 

In  accoroance  with  the  fixed  level  property,  write  down  and 
read  up  operations  on  segments  will  be  prohibited.  Also,  in 
order  to  prevent  sabotage,  write  up  operations  on  segments 
will  be  prohioited.  Kith  these  restrictions  erforcec, 
sharin'!  of  segments  among  processes  having  different 
clearances  cannot  compromise  irfcrmation. 

The  access  permitted  a giver  process  to  a giver  seqment  will 
oe  computed  as  follows*  If  the  clearance  of  the  orocess  is 
lower  than  tne  classification  of  the  segment,  fhe  orocess 
will  be  giver  null  access  to  the  segment.  If  the  clearance 
of  the  process  equals  the  class!  fication  of  the  segment,  the 
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process  Mill  be  given  whatever  node  of  access*  If  ary.  is 
soecifiea  in  the  ACL.  If  the  clearance  of  the  process  is 
higher  than  the  classification  of  the  segment*  the  process 
Mill  be  given  the  mode  of  access  specified  in  the  ACL  minus 
Mrlte  permission. 

In  order  to  reference  a segment,  a process  must  first 
"initiate**  the  segment  into  its  address  space.  At 
initiation  time*  the  access  computation  described  above  will 
be  performed  to  determine  if  the  process  has  any  access  to 
the  segment.  If  so,  the  segment  will  be  aaced  to  tre 
address  space  of  the  process.  Thereafter,  all  references  to 
the  segment  will  be  valioated  by  the  processor  haraware. 
fach  segment  fault  taken  by  the  process  on  the  segment  will 
force  access  to  be  recomputed  by  the  above  method. 

3.6.3  Implications 


The  rules  governing  access  to  segments,  while  satisfying 
secunity  requirements,  have  certain  curious  implications 
worth  noting.  A problem  arises  over  the  fact  that  for  each 
user  there  tyoical  ly  exists  a number  of  c or re  soon ai ng 
writeable  oata  segments  (e.g.  mailboxes,  console  message 
segments,  abbrev  profiles,  piro*d  files).  Conceptually,  it 
makes  little  sense  to  segregate  the  functions  of  these 
segments  according  to  process  clearance.  Never tre I ess , 
these  segments  must  pe  assigned  a specific  c I assi flea* 1 on 
and  hence.  will  be  writeable  by  a process  at  one  clearance 
level  only.  As  a result,  the  user  who  operates  at  more  than 
one  clearance  level  must  sacrifice  a certain  amount  of 
flexibility  and  convenience  in  sending  and  receiving  mail, 
creating  abbreviations,  updating  pmotd  files,  et<~. 


3.7  ACCESS  TO  DIRECTORIES 


3.7.1  Classification  of  Directory  Information 

Every  directory  has  a classification  defined  by  t level  and 
a category  set. 
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The  classification  of  a directory  cannot  be  less  thsn  the 
classification  of  its  oarent  directory.  This  restrict  Ion  is 
necessary  in  order  to  eliminate  a write-down  information 
channel  using  directory  names.  Suooose*  for  example,  that 
an  unclassified  directory  were  permitted  to  exist  in  tre 
hierarchy  below  a Secret  directory.  A Secret  process  could 
change  the  name  of  the  Secret  directory,  thereby  also 
changing  the  pathname  of  the  unclassified  olrectory.  This 
action  could,  of  course,  be  cetected  by  an  unclassified 
process.  Therefore,  it  is  necessary  that  a olrectory  ana, 
for  that  matter,  a segment,  have  an  equal  or  greater 
classification  than  its  parent  directory.  This  rule  Is 
hereafter  referred  to  as  the  "ron-decr eas ing  c I ass  1 f i ca 1 1 cn 
rule.**  For  reasons  explained  below,  the  classification  of  a 
segment  is  further  restricted  to  be  equal  to  that  of  its 
parent  directory. 

As  with  segments,  a directory  will  initially  receive  the 
same  classification  as  its  parent  directory.  However,  a 
special  “upgrade**  operation  will  be  available  which  permits 
a user  to  raise  the  classification  of  a directory.  It  is 
required  that  a directory  be  empty  in  order  to  be  upgraceo. 
Otherwise,  after  upgrading,  inferior  segments  or  directories 
would  stand  in  violation  of  the  non-aecreaslng 
classification  rule.  If  the  entire  subtree  of  a directory 
were  upgraded,  a potential  for  unwanted  over c I ass i f ica t i on 
would  exist.  (Also,  implementation  would  be  cifficult.) 

Several  problems  arise  with  respect  to  the  branch  of  an 
upgraded  directory.  Since,  as  described  so  far,  such  a 
branch  is  contained  in  a superior  directory  of  lower 
classification,  a user  having  access  to  an  upgraded 
directory  would  not  be  permitted  to  modify  its  branch.  This 
restriction  would  be  very  inconvenient  in  practice. 
However,  a mora  serious  problem  is  posed  by  the  fact  that  a 
user  having  access  to  an  upgracec  directory  would  be  able  to 
implicitly  modify  its  branch.  For  example,  by  increasing 
the  size  of  an  upgraded  directory,  one  could  change  the 


39 


current  length  attribute  in  its  branch.  This  constitutes  a 
write-down  information  channel. 


In  order  to  eliminate  the  above  problems*  an  individual 
branch  will  have  the  same  classification  as  the  segment  or 
directory  wnich  it  describes*  rather  than  that  of  its 
containing  directory.  Only  upgraded  branches  are  actually 
affected  by  this  new  definition*  since  non-upgradeo  branches 
will  still  have  the  same  cl assi  fication  as  their  containing 
directory  anyway. 

The  classification  of  a branch  applies  to  all  data  1 tees 
within  the  branch  except  for  tne  branch  names.  These  names 
retain  the  classification  of  the  containing  directory. 
Names  are  separated  from  the  branch  in  this  way  in  order  to 
avoid  creating  still  another  write-down  information  channel. 
If  the  name  of  an  upgraded  directory  could  be  modified  by  a 
process  at  the  “level"  of  the  branch*  then  a lower-level 
process  could  detect  such  modifications  by  adding  names  to 
non-upqraded  branches  in  the  same  directory  and  observing 
whether  name  duplications  occurred.  Hence*  branch  names  can 
only  be  modified  by  a process  at  the  "level"  of  the 
containing  directory. 


3.7.2  Explicit  Operations  on  Directories 

Whenever  the  supervisor  is  explicitly  reauested  to  perform 
an  operation  on  a directory,  a checK  will  be  made  to  ensure 
that  the  user  has  the  right  to  perform  the  operation 
accoralng  to  the  current  Multics  access  control  rules  and 
the  new  fixed  level  property  rules.  In  particular,  the 
supervisor  will  refuse  any  request  that  woulo  result  in  a 
"read  up"  or  a "write  down"?  it  will  also  refuse  all 
requests  that  could  result  in  sabotage  by  "writing  uo." 

Operations  that  would  return  to  the  caller  any  part  of  a 
directory  having  the  same  classification  as  +he  directory 
itself  will  be  executed  only  if  the  clearance  of  the  process 
is  equal  to  or  higher  than  the  classification  of  the 
directory.  Examples  of  these  operations  include  listing  a 
directory,  listing  tne  initial  ft  CL , and  reading  tne  quote. 


Operations  that  would  modify  any  part  of  a directory  having 
the  same  c I ass  i f ic at i on  as  the  directory  itself  will  be 
executed  only  if  the  clearance  of  the  process  Is  eaual  to 
the  classification  of  the  directory.  Examples  of  these 
operations  include  acding  or  celeting  entry  names*  changing 
the  initial  ftCL,  and  creating  a new  branch  (slrce  a brancn 
is  originally  created  with  the  classification  of  its 
containing  directory).  The  deletion  of  branches,  both 
upgraded  and  non-upgraded*  is  also  included  In  this  catecory 
since  it  involves  the  deletion  of  branch  names.  Note, 
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however,  that  this  do«s  not  constitute  • Means  of  sabotaging 
an  upgraded  directory  since  it  is  required  that  an  upgraoed 
directory  ba  empty  in  order  to  delete  it.  Subtrees  are 
always  deleted  in  a dcttom-up  fashion.  Therefore*  a user 
able  to  delete  an  empty  upgraded  directory  Mill  not  be  able 
to  delete  that  same  directory  when  there  exist  inferior 
segaents  or  directories  to  which  he  has  no  access. 

Operations  that  would  return  to  the  caller  any  part  of  a 
branch*  other  than  the  entry  names*  will  be  executed  only  if 
the  clearance  of  the  process  is  equal  to  or  higher  than  the 
classification  of  the  branch  itself.  Examples  of  such 
operations  include  reading  the  branch  status*  reading  tre 
ACL*  reading  the  ring  brackets*  reading  the  bit  count* 
reading  the  date-time  used  or  mocified. 

Finally*  operations  that  would  mcdify  any  part  of  a oranch 
other  than  the  entry  names  will  be  executed  only  if  tre 
clearance  of  the  process  is  equal  to  the  c I ass  1 f icat i cn  of 


the  branch.  Examples 
the  ACL*  changing  the 


of  such  operations  irclude  changing 
bit  count*  changing  the  maximum 


length*  and  changing  the  safety  switch. 

The  “moveauo  ta**  operation  is  unique  in  the  sense  that  it 
modifies  two  directories  at  once*  one  immediately  inferior 
to  the  other.  A problem  arises  when  Quota  is  moved  to  or 
from  an  upgraded  directory.  To  do  this*  a process  is 
required  to  modify  two  Directories  of  different 
classifications  which  is  normally  not  permitted.  Since 
writing  down  must  be  pronibitec,  a process  at  the  "level"  of 
an  upgraded  directory  cannot  be  allowed  to  move  quota 
between  that  upgraded  directory  and  its  Parent  directory. 
Therefore,  the  movement  of  quota  to  or  from  an  upgraded 
directory  will  be  performed  only  by  a process  at  the  "level" 
of  the  parent  directory.  (Modify  permission  or  the  ACL  of 
both  directories  will  still  be  requlrea.l  The  fact  that  a 
lower-level  process  will  be  able  to  withdraw  quota  from  an 
upgraded  directory  constitutes  a milu  form  of  sabotage  which 
can  only  temporarily  impede  a higher-level  process*  but 
cannot  destroy  or  compromise  information.  This  is  not  felt 
to  be  a serious  problem  since  this  could  be  auditable  and 
quota  can  easily  be  restoreo.  The  alternative  of  not 
allowing  quota  to  be  withdrawn  from  an  upgraded  directory 
except  by  special  action  of  the  SSO  is  considerably  less 
attractive. 


The  new  upgrade  operation  for  directories  is  also  rather 
unique.  Since  it  involves  modifying  an  element  of  a branch* 
it  can  only  be  oerformed  by  a process  at  the  same  "level**  as 
the  branch.  In  addition,  the  oirectory  to  be  upgraded  must 
be  empty  as  mentioned  above.  Furthermore*  for  reasons  to  be 
explained  shortly*  the  directory  to  be  upgraded  must  have  a 
terminal  quota. 
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3.7.3  Implicit  Operations  on  OIrectorles 


k As  described  above*  addltloral  access  checking  can  be 

performed  for  all  explicitly  requested  directory  opera+iors 
! so  as  to  comply  with  the  fixed  level  property  rules. 

Unfortunately*  however,  there  exists  a class  of  implicit 
directory  operations  which  present  a more  difficult  problem. 
An  implicit  directory  operatior  is  basically  a side-effect 
of  some  action  performed  outside  the  directory.  One  such 
f operation*  the  changing  of  the  current  length  attribute*  has 

already  been  discussed.  Three  other  implicit  directory 
operations*  which  are  the  changing  of  quota  used*  date-time 
used  (dtul*  and  date-time  mocified  (dtml*  still  causa 
problems  within  the  directory  access  scheme  oascribec  thus 
I*  far.  These  oroblems  are  discussed  below. 
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3. 7.3.1  The  Quota  Used  Problem 

Changing  the  number  of  pages  usee  by  a segment  or  directory 
causes  the  “quota  used”  number  to  be  Incremented  or 
decremented  in  all  superidr  directories  up  to  and  including 
the  nearest  superior  directory  having  a terminal  quota.  If 
this  chain  of  suoerlor  directories  Includes  one  or  more 
directories  of  a lower  c I ass  if cat  ion  than  the  segment  or 
directory  being  modifiec*  then  a write-down  information 
channel  exists.  There  are  three  methods  of  performing 
write-down  operations  on  this  information  channel*  1> 
changing  the  number  of  pages  usee  by  segments  in  an  uograced 
directory?  2)  increasing  the  pages  used  by  an  upgraded 
directory  itself?  and  3)  increasing  the  pages  jseo  by  the 
parent  of  an  upgraded  directory  due  to  an  increase  of  the 
upgraded  branch. 
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The  First  Method 

Changing  the  length  of  segments  to  reflect  the  "guota  useo" 
up  the  chain  of  superior  directories  is  the  most  flexible 
method  of  using  this  Information  channel.  However,  this 
facet  of  the  problem  can  be  blocked  by  reaulring  that  a 
segment  have  the  same  classification  as  its  parent  directory 
and  that  every  upgraded  directory  have  a termiral  aucta.  In 
this  way,  the  pages  of  a segment  are  always  chargeo  to  tha 
quota  of  a superior  directory  having  the  same  classification 
as  the  segment.  Hence*  one  cannot  pass  information  aown 
merely  by  changing  the  size  of  a segment  and  causing  the 
“quota  used”  number  to  change  in  some  superior  directory. 
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The  Secono  Method 


Pages  of  an  upgraded  directory  itself  are  chargeo  to  a 
superior  directory  of  tower  classification*  This  could 
become  a write-oown  information  channel  wnen  a process  of 
clearance  X adds  branches  to  an  upgraded  directory  with 
classification  X*  causing  the  ruaber  of  directory  pages  to 
grow.  The  “quota  used"  number  in  the  suoerior  directory 
would  reflect  this  change  ano  could  thus  be  seen  by  a 
process  whose  clearance  was  lower  than  X.  However*  deleting 
branches  will  not  cause  the  size  of  a directory  to  decrease* 
(This  is  true*  due  to  the  current  implementation  of 
director! es. ) If  this  facet  of  the  quota  problem  was  not 
eliminated*  its  usefulness  as  a means  of  compromising 
Information  for  the  malicious  user  is  still  very  limited 
sincel 

- tt  can  only  be  used  by  a Troian  Horse  or  cooperating 
processes  (Sae  Section  3*5*5). 

- A process  can  only  Influence  the  size  of  a directory  in  a 
secondary  manner*  such  as  by  creating  a new  branch  and 
checking  to  see  if  the  olrectory  is  large  enough. 

- A process  can  write-down  only  6 bits  (1  8C0  character) 

per  directory  ( l to  64  pages*)  Using  two  upgraded 
directories  in  the  same  parent  will  not  be  much  help 
since  it  would  provide  only  7 bits*  due  to  the  acoitive 
nature  of  the  "quota  used". 

- To  use  this  information  channel  for  writing-down  N 
characters  (6*k  bits)  in  parallel*  a malicious  user  would 
require  N directories  of  the  lower  classification,  each 
with  an  upgraded  directory,  and  a starting  pool  of  at 
least  66 *N  unused  pages  of  his  quota* 

- A directory  cannot  be  decreased  in  length  by  a process. 
This  can  only  be  done  by  a long  salvage  after  a system 
shutdown  or  oy  deleting  the  directory  (a  process  with  the 
clearance  to  add  branches  to  an  upgraded  directory  ooes 
not  have  the  clearance  to  delete  the  directory). 

- A process  must  delete  all  branches  in  the  upgraded 
directory  and  synchronize  (using  another  directory)  with 
a process  of  lower  clearance  to  have  the  upgraded 
directory  deleted  and  recreated*  before  another  6 bits  of 
information  can  be  passeo.  Otherwise,  a record  quota 
overflow  will  be  reached  rather  quickly. 

This  information  channel  could  be  eliminated  by  charging  all 
directory  pages  to  its  own  quota*  However,  this  involves  a 
redesign  of  the  entire  quota  mechanism  and  would  impact  the 
activation  and  deactivation  of  directories*  Therefore*  due 
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to  the  limited  effectiveness  of  the  information  channel  and 
the  high  cost  of  correction,  no  attempt  Mill  be  made  to 
close  this  write-down  channel.  However,  for  added  assurance 
that  it  is  not  being  used  as  a means  for  compromising  data* 
the  creation  of  uogracec  olrectorles  ano  ever  the 
"get_quota**  operation  can  be  audited. 


The  Thirc  Method 

This  problem  is  a result  of  the  basic  design  of  a 
hierarchical  storage  system  Mhlch  uses  variable  lengtn 
branch  entries  ano  contains  data  of  mere  than  one 
classification.  The  space  useo  by  the  branch  of  an  upgraded 
directory  is  contained  in  a superior  directory  of  lover 
classification.  Hence,  by  adding  ACL  entries  to  an  upgraded 
branch,  one  could  affect  the  current  lencth  of  a lever 
classified  directory,  vhich  is  in  turn  reflected  in  the 
“quota  used**  in  the  parent  of  that  directory.  This  facet  of 
the  quota  problem  also  requires  the  use  of  a Troian  Horse 
and  is  even  more  cumbersome  than  the  others.  It  can  only  be 
eliminated  by  restricting  upgraced  branches  to  a fixed 
number  of  ACL  entries.  The  changes  describeo  to  close  the 
second  facet  of  the  quota  problem  vould  not  help  this  one. 
The  solution  of  restricting  ACL  entries  does  not  generalize 
properly  for  1 mo  I ementat ion  ano  presents  a very  strange  user 
interface.  Until  a correct  I eng  term  solution  can  oe 
designed,  no  attempt  vlll  oe  mace  to  eliminate  the  last  two 
facets  of  the  quota  problem. 


.2  The  OTU  and  QTM  Problem 

Every  branch  contains  tvo  items  Known  as  the  date-time  used 
and  tne  date-time  medifieo.  A process  vltn  clearance  X can 
reference  a segment  with  a classification  lower  than  X 
causing  its  dtu  to  be  updated.  This  updated  ctu  can  then  be 
observed  by  a process  with  a clearance  lower  than  X and 
hence,  write-down  channel  exists.  In  fact,  whenever  any 
segment  is  referenced,  all  of  its  superior  directories  must 
first  be  activated.  Since  act  Iv  <t Ion  is  synonymous  with  use 
in  the  present  system,  the  atu's  of  all  superior  directories 
are  updated  whenever  a segment  is  referenced.  A similar 
problem  is  Dosea  by  otm.  The  modification  of  a segment  or 
alrectory  causes  the  updating  of  dtm  not  only  tor  that 
segment  or  directory,  but  for  all  superior  directories  as 
well.  (This  is  done  to  aid  the  bacKuo  system  in  locating 
modified  segments  ana  directories  without  excessive 
searching.) 


In  order  to  eliminate  the  write-down  channel  causeo  by  the 
upwards  propagation  of  dtu  and  dtm,  new  interpretations  will 
be  given  these  two  attributes  with  resoect  to  directories. 


Currently*  atu  and  Jtm  refer  to  the  entire  subtree  of  a 
directory.  Instead*  dtu  anc  at m Mill  be  maae  to  refer  to 
the  directory  Itself.  A nett  entry  Item  called  “date-time 
subtree  modified"  (dtsm)  Mill  be  Keot  to  maintain  oumcirg 
efficiency.  The  dtsm*  however.  Mill  be  available  only  to 
the  dumper  process  ano  not  to  ordinary  users.  (See 
Section  3.121 


In  order  to  prevent  writing  down  via  dtu*  it  Mill  be 
necessary  to  further  alter  the  interpretation  of  ctu. 
Specifically*  dtu  Mill  hold  the  time  that  a segment  Mas  last 
referenced  by  a process  of  the  seme  "level"  as  the  segment. 
In  other  words*  the  reading  of  a segment  with  classification 
X by  a process  with  a clearance  higher  than  X Mill  be 
"transparent"  as  far  as  dtu  is  concerned.  The  same  will 
also  be  true  for  directories.  Notice  that  dtu  will  retain 
its  present  meaning  for  any  segment  which  is  referenceo  only 
by  processes  of  the  same  "level."  This  change  in  meaning  is 
acceptable*  because  dtu  is  primarily  used  in  an  Interface 
where  precision  is  not  required.  Otu  is  primarily  usee  to 
order  the  output  of  the  list  command  and  to  delete  all  files 
not  used  in  some  period  of  time.  Thus*  a precise  otu  is  not 
essent  ial . 


Implementation  of  tn 
relatively  simole. 
(gtus)  contained  in 
new  fashion  so  as 
Whenever  a segment  i 
if  the  activating  or 
set  as  the  segment. 
Thereafter*  any  proc 
segment  will  turn  o 
category  set  as  the 
rule  will  be  spec i a 
dumper  and  reloade 
Whenever  the  branch 
for  the  segment  w 
segment  is  off. 


is  new  interpretation  of  dtu  will  be 
The  global  transoarent  usage  snitch 
each  AST  entry  will  be  manipulated  lr  a 
to  properly  control  the  setting  of  atu. 
s activatec*  the  gtus  will  be  turned  off 
ocess  has  the  same  level  and  category 
Otherwise*  the  gtus  will  be  turned  on. 
ess  which  takes  a segment  fault  on  that 
ff  the  gtus  if  It  has  the  same  level  and 
segment.  The  only  exceptions  to  this 
I transparent  system  processes  (e.c.  the 
rl  which  will  never  turn  off  gtus. 
of  an  active  segment  is  updateu*  the  dtu 
ill  be  reset  only  if  the  gtus  for  the 


3.8  ACCESS  TO  I/O  CHANNELS 


3.8.1  Requirements 

No  user  process  stout  c be  able  tc  directly  attach  any  I/O 
device  other  than  a terminal  and  then  only  if  it  has  been 
specifically  allocated  to  the  process  by  a system  process. 

Each  I/O  device  must  be  identified  with  a I eve  I /category . 

Any  process  performing  I/O  on  a device  must  only  be  able  to 
perform  the  operations  allowed  by  the  fixed  level  property 
rules  (l.e.  only  read  from  a lower  •’level"  device*  only 
write  to  a higher  "level"  device*  and  reao/write  to  a device 
of  the  same  "level”!. 

The  "level"  of  a device  must  be  subject  to  change  by  the 
system  operator. 

The  initial  “level"  of  each  device  must  be  control  lec  by  the 
System  Security  Officer. 

Teletype  channels  must  be  identified  with  a maximum  "level." 
so  that  a user  can  only  create  a process  of  a "level"  equal 
to  or  below  the  maximum. 


3.8.2  Design  Considerations 

One  approach  considered  was  removing  current  n cs_  entries 
for  device  attachment  and  using  a new  gate  to  restrict 
attachment  of  all  devices  other  than  terminals  to  system 
daemons  only.  This  approach  would  require  either  a ring 
four  write-around  for  hcs_  or  else  the  modification  cf  all 
ring  four  modulas  that  reference  hcs_  attachment  primitives. 

An  additional  consideration  was  to  have  the  system  control 
process  manage  teletype  channels  entirely.  This  concept 
went  along  with  the  previous  approach,  so  that  terminals 
coula  be  handled  in  a slightly  ditferent  manner  *no  still  oe 
attached  by  user  processes.  Complete  system  con*ro'  process 
management  of  teletypes  was  rejected  because,  ulth  full 
system  control  process  management  of  teletype  channels, 
there  are  no  ring  0 mooules  irvolved  in  the  attachment 
oecision,  only  in  tne  actual  attachment  operation. 
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Another  approach  to  managing  I/O  devices  was  to  raw* 
separata  device  lists*  one  for  systea  devices  and  one  for 
user  devices*  The  noraat  user  attempting  to  attach  any 
device  would  check  only  that  list  which  applleo  to  hiw.  The 
configuration  deck  was  suggested  as  a cortrol  for  the 
memberships  of  these  lists*  This  idea  was  also  rejected* 

The  most  promising  suggestion  involved  adding  a new  ring  0 
table*  called  the  Peripheral  Assignment  Table  (PAT)*  which 
would  be  referenced  on  each  attachment  operation*  to  provide 
a level/category  check  of  the  device  that  a process  is 
atteaptlng  to  attach*  This  idea  was  adopted  as  part  of  the 
Oesign  Approach* 


3*8*3  Oesign  Approach 

The  Peripheral  Assignment  Table  (PAT)  concept  will  be 
Integrated  into  existing  ring  o tables.  Each  device  which 
could  be  attached  to  a process  will  be  described  In  this 
table*  The  maxiaum  mode*  classification  level  and  category 
set  will  be  Included  in  the  entry  for  each  device.  If  a 
process  attemots  to  attach  a device*  the  clearance  of  the 
process  will  be' compared  to  the  classification  of  the  oevlce 
to  ensure  that  the  process  wi  II  not  “write  down**  or  "read 
up."  The  "write  up"  capability  will  be  allowed  only  if  the 
device  is  a “write  only"  device  (e.g.*  a printer). 

The  use  of  the  PAT*  as  described  above*  provides  assurance 
that  normal  I/O  operations  will  adhere  to  the  fixed  level 
property  rules*  It  does  not*  however*  prevent  the  possible 
exploitation  of  flaws  in  ring  0 I/O  procedures.  The 
exploitation  of  "bugs"  contained  in  I/O  proceoures  has  been 
a traditional  means  of  breaking  the  security  of  «any 
computer  systems.  Therefore*  until  ring  0 I/O  procedures 
can  be  certified  correct*  only  trusted  systea  processes  will 
be  permitted  to  directly  attach  any  I/O  devices  other  than 
terminals*  This  restriction  will  be  enforced  by  moving 
attachment  entries  from  hcs_  to  a new  gate  accessible  to 
system  daemons  only*  An  hcs_  write-around  will  be  provided 
so  that  existing  daemon  software  will  not  require 
modi f leaf  Ions. 

Any  process  requesting  a tape  drive  to  be  attached  must  use 
the  new  ring  ene  tape  management  software  (THS).  The  TMS 
will  maintain  a tapa  descriptor  segment  tor  each  face 
registered  on  the  system.  At  attachment  time  the  segment 
for  the  particular  tape  will  be  checked  to  fine  the 
requestor’s  "need  to  know"  access  and  the  classification  of 
the  tapa.  A massage  will  be  sent  to  the  tape  allocator 
process  to  assign  the  requesting  process  a drive  of  the  same 
"level"  as  the  tape*  (Note*  at  this  point*  the  ring  one  TMS 
is  choosing  the  "level"  of  the  drive  based  on  the 
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classification  of  th«  tape  descriptor  segment.)  When  the 
•cunt  reauest  is  sent  to  the  operator*  the  drive 
classification  Mill  be  specified  (correctly)  and  the 
operator  must  verify  that  the  tape  requesteo  has  the  sate 
“level"  as  the  drive.  This  can  easily  be  oone  by  cclor 
ceding  and  plainly  earning  the  correct  c I ess  1 f icat lor  on 
beth  reels  and  drives.  The  tape  mount  must  be  re|ected  (and 
the  System  Security  Officer  notified)  if  there  is  any 
discrepancy.  (see  Section  3*10  for  »ore  details  or  tape 
I/O).  It  must  be  noted  that  primary  control  on  tape 
security  is  the  system  operator.  The  TMS  can  only  check  the 
operator.  If  the  operator  makes  a mistake  or  is  “spoofed"* 
the  TMS  cannot*  in  general*  detect  the  error. 

There  must  be  a way  to  maintain  operational  procecure 
consistency  and  yet  allow  the  system  control  process* 
running  at  the  unclassified  level  (see  Section  3.11)*  to 
read  Top  Secret  backup  tapes  during  reload.  Operational 
consistency  requires  the  Top  Secret  tapes  to  be  mounted  on  a 
Top  Secret  tape  drive.  Therefore*  a means  will  be  croviced 
for  the  system  control  process  to  bypass  the  fixed  level 
property  restrictions  so  it  will  be  able  to  “read  up"  in  a 
carefully  controlled  tanner. 


3.9  SYSTEM  PROCESSES  ANC  SYSTEM  FUNCTIONS 
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Many  system  services  such  as  logging  in  ana  logging  out  a 
user,  printing  a segment  on  the  printer  for  a user.  saving 
the  contents  of  the  disks  on  tape,  restoring  the  contents  cf 
the  disks  from  taoe.  restorirg  the  contents  of  the  disks 
when  they  have  Deen  damageo,  retrieving  a segment  that  has 
been  lost,  are  performeo  by  special  processes,  known  as 
“system  processes."  Clearly,  these  processes  neeo  unusuel 
power  in  order  to  be  able  tc  carry  out  their  |ob,  and,  cy 
their  nature,  cannot  operate  at  any  single  clearance  level 
without  violating  the  fixed  level  property  restrictions; 
however,  they  must  violate  the  fundamental  security 

rules. 

For  example,  some  of  these  processes  need  tne  "reao"  and 
"write**  capabilities  cn  all  segments  In  the  system.  Some 
need  the  "status"  and  "mocify"  capabilities  on  all 
directories  in  the  system;  some  need  to  communicate  back 
and  forth  with  all  processes  ir  the  system;  some  need  to  be 
able  to  attach  any  I/O  channel.  It  is  obvious  that  there 
exists  no  clearance  which  woule  give  a system  process  the 
right  to  perform  its  Job,  and  still  adhere  to  the  fixed 
level  property  requirements.  However,  for  certification 
purposes,  there  us  a very  strong  desire  to  assign  a level 
and  category  to  all  processes  in  the  system  without 
exception.  It  is  unoerstood,  of  course,  that  system 
processes  must  not  oe  bouno  by  the  fixed  level  crooerty 
restrictions  in  order  to  perform  certain  tasks;  therefore, 
the  programs  in  these  processes  must  "in t er ore t i v e I v" 
enforce  the  fundamental  security  rules. 

Use  of  interpretation  rather  thar  fixed  level  property  rules 
by  a system  orocess,  as  part  of  normal  system  operation, 
will  be  called  an  “ interpret  ive  operation."  Any 
interpretive  operations  should  fall  into  one  of  the 
following  classes! 

a.  Access  to  Segments!  the  retriever  process  and  the 
system  control  process  (when  reloading)  must  be  able  to 
read  and  write  segments  of  any  classification,  but  jgoix 
to  copy  properly  classified  information  to  anc  from 
tape.  The  I/O  coordinator  and  also  the  system  control 
process  must  be  able  to  share  message  segments  with 
user  processes  of  any  clearance. 
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b.  Access  to  Directories!  tbe  system  control  orocess  and 
the  retriever  orocess  must  be  able  to  perform  specific 
operations  In  any  directory. 

c.  IPCt  the  I/O  coordinator  as  well  as  the  system  control 
orocess  must  be  able  to  receive  "wakeuos"  from 
processes  of  any  clearance.  using  the  interprocess 
communication  facility. 

d.  I/O  Channels!  the  system  control  process  must  be  able 
to  attach  an  I/O  channel  of  any  c I ass  1 f ic at i or  (See 
Sect  ion  3*9) . 

Since  it  is  desirable  to  minimize  interpretive  operations, 
the  strategy  for  assigning  a level  to  a system  process  is  to 
select  the  one  which  causes  the  fewest  Interpretive 
ooerat  ions . 

An  interpretive  operation  always  involves  e orocess,  an 
object,  and  a time  interval.  For  each  interpretive 
operation  which  it  performs,  a system  process  must  obtain  an 
“exception  permission. “ An  exception  permission  can  be 
represented  by  the  triple  (P,G,T>  — a process  p is  allowed 
to  violate  the  fixed  level  property  with  respect  to  object  0 
for  time  interval  T.  From  the  viewpoint  of  a given  system 
process,  each  exception  permission  Is  represented  by  an 
object  or  set  of  objects  and  a time  interval.  For  example, 
if  the  unclassified  I/O  coorcinator  needs  to  read  a Too 
Secret  message  segment,  the  exception  permission  represented 
by 


(all  segments,  lifetime  of  the  process) 

is  sufficient  to  allow  the  interpretive  operation  to  occur, 
A second  permission, 

(all  message  segments,  lifetime  of  the  process) 

is  more  restrictive  but  still  allows  the  ODeraMor. 
Finally,  a third  permission, 

(all  message  segments,  while  the  process  is  in  ring  i) 

is  even  more  restrictive  but  still  sufficient.  Each 
exception  permission  has  a smaller  “exception  envelope'*  fran 
the  preceding  one.  The  second  permission  restricts  the 
class  of  objects,  whereas  the  third  permission  restricts  the 
time  interval  as  well.  This  example  serves  to  motivate  the 
notions  of  “ob|ect  granularity"  and  “time  granularity." 
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Tne  second  permission  has  a finer  oblert  granularity  than 
the  first*  while  the  third  permission  has  a finer  flee 
granularity  than  either  of  the  first  two.  Granularity 
should  be  interpreted  to  be  the  scope  or  envelope  of  access 
granted  to  a system  process  for  an  interpretive  operation. 


For  any  interpretive  operation*  the  finest  grarularity  which 
still  allows  the  operation  is  most  desirable  from  the 
standpoint  of  the  principle  of  least  privilege.  For  the 
above  example*  the  class  of  ob|ects  (which  has  only  one 
member)  represented  by 


(the  TS  message  segment  for  dprint  queue' 3 to 
the  printer  in  room  405) 


may  well  have  the  finest  sufficient  object  granularity. 


Two  general  approaches  to  maraging  the  use  of  exception 
permissions  have  been  considered  during  the  design  analysis. 
These  two  approaches*  cal  lea  the  "privileged  function" 
approach  and  the  “privileged  process"  approach,  are 
described  below. 


The  privileged  function  approach  is  one  which  permits  the 
finest  possible  time  ana  ob|ect  granularity  to  ba  enforcec. 
Essentially*  this  approach  provides  a special  ring  0 
primitive  to  perform  each  different  interpretive  operation. 
Access  to  these  privileged  functions  is  restricts  to 
specific  system  processes  by  use  ot  ring  o gates  having 
appropriate  access  control  lists.  Unaer  this  scheme,  object 
granularity  can  be  made  as  subtle  as  one  desires.  Also, 
time  granularity  can  be  tightly  controlled.  If  an 
interpretive  operation  is  performed  entirely  within  ring  3, 
then  The  call  into  ring  0 end  the  corresponding  return 
delimit  the  time  Interval  of  the  exception  permission.  It 
Is  not  on  I y the  absolute  size  of  the  time  interval  »hlcf  is 
significant,  but  also  the  fa<-T  that  control  never  exits  the 
trusted  ring  0 domain  during  tne  Interval.  Hopefully,  this 
will  reduce  the  effort  needed  to  certify  outer  ring 
procedures  which  oerform  interpretive  operations.  The 
privileged  function  approach  also  provides  a very  nature! 
and  simple  means  for  auditing  interpretive  operations. 


The  privileged  fgnetior  approach  is  not  without  its 
disadvantages  ana  limitations  from  the  viewpoint  of  impact 
on  current  imD I ementat  ion.  The  use  of  restrlctea  gates 
tends  to  tie  procedures  to  processes.  Currently  in  Multlcs, 
system  processes  use  many  of  the  same  library  procedures  as 
do  other  processes.  If*  however,  system  processes  were 
required  to  employ  special  gates  to  oerform  privileged,  but 
otherwise  common  operations  (e»g.  deleting  a segment),  then 
special  versions  of  many  library  procedures  would  be  neeoea. 
The  daemon  software  Itself  would  require  numerous 
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modifications  to  convert  calls  to  standard  library 
procedures  and  standard  ring  0 gates  to  calls  to  special 
library  procedures  and  special  ring  0 gates.  And*  of 
course*  the  nett  ring  0 privllegec  functions  mould  have  to  be 
provided.  Therefore*  from  an  impl ementa  ion  standpoint,  the 
privileged  function  approach  is  unattractive.  Also*  it 
should  be  recognized  that  this  approach  is  not  appropriate 
for  all  types  of  interpretive  operations.  For  examcle* 
asynchronous  events,  such  as  the  receipt  of  an  i pc  makeup* 
cannot  be  handled  in  this  manner.  In  many  cases*  the  time 
interval  of  an  exception  permission  cannot  be  tightly 
controlled.  Consider,  for  example*  the  use  of  privileged 
functions  to  initiate  segments  or  to  attach  I/O  channels. 
Although  the  granting  of  these  privileges  can  be  restricted 
to  ring  o,  the  subsequent  use  of  these  privileges  cannot  be 
so  restricted.  Hence*  mhife  it  may  not  be  difficult  to 
locate  the  intervals  mithlr  a program  in  mhlch  an  exception 
permission  is  in  use,  it  mill  be  necessary  to  trace  all 
possible  s i de- e f f ec  t s • System  auditors  must  ensure  that  a 
system  process  is  memoryless  with  respect  to  each  fixed 
level  property  exception.  This  mill,  in  gereral*  require 
full  examination  of  every  program  mhlch  performs 
interpretive  operations.  Hence,  a substantial  certification 
effort  mill  still  be  required  for  outer  ring  daemon 
programs. 


The  privileged  process  approach  to  handllrg  interpretive 
operat  ions  is  one  mhich  attempts  to  minimize  implementation 
difficulty.  In  its  simplest  form,  this  approach  merely 
requires  a oar-orocess  smi tch  to  indicate  mhether  or  not  a 
process  has  “system  pr  ivi  I eges  .**  This  smitch  (presumably 
storeo  in  the  pds)  mould  be  interpreted  by  those  ring  0 
reoauies  responsible  for  access  computation.  Essentially, 
fixed  level  property  access  checking  mould  be  effectively 
disabled  for  all  processes  having  system  privileges. 
Clearly*  this  scheme  requires  comparat lve i y little  effort  to 
implement.  Ail  that  is  necessary  is  a mechanist  to 
Initialize  the  privilege  smitch  and  modifications  to  suspend 
fixed  level  property  access  checking  for  processes  having 
the  smitch  turned  on.  un f ortun at e I y * this  approach  pays 
little  heed  to  the  principle  of  least  privilege.  Also,  this 
approach  has  the  disadvantage  that  fixed  level  property 
exceptions  occurring  mithir  a program  mill  not  be  explicit 
in  the  code*  but  rather  implicit  in  the  fact  that  the 
executing  process  has  system  privileges*  Thus,  the  task  of 
cer t i f leaf  ion  seems  more  difficult  as  compared  to  the 
privileged  function  approach. 

The  basic  privileged  process  approach  could,  of  course*  be 
greatly  elaborated.  Object  granularity  coula  be  enhancec  by 
use  of  multiple  switches*  each  correspond ing  to  a different 
class  of  objects.  Also*  time  granularity  could  he  enhanced 
by  setting  and  resetting  these  switches  frequently.  Taken 
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To  the  limit,  this  scheme  begins  to  resemble  the  privileged 
function  approach.  A switch,  or  set  of  switches,  coulc  be 
turned  on  before  each  standard  ring  o call,  and  then  reset 
upon  return.  However,  the  finer  the  granularity,  the  more 
difficult  the  implementation;  hence,  the  principal  advantage 
of  the  privileged  process  approach  is  lost. 

il  *S,«X*eCt!d  tha!,  S0Be  hybrla  of  the  two  approaches 
described  above  will  be  adopted  in  order  to  obtain  a 

practical  compromise  between  ease  of  validation  and  ease  of 
implementation.  The  specific  nature  of  the  hybrio  approach 
will  depend  upon  design  details  to  be  considered  during 
implementation. 


3.10  I/O  DAEMON  CONTROL  IN  A SECURE  ENVIRONMENT 
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3.10.1  Requirements 

The  primary  requirement  of  the  Air  Force  Data  Services 
Center  is  that  no  user  of  the  Mul tics  system  be  able  to 
directly  control  any  external  I/O  device  (other  than  his  own 
terminal).  Therefore*  each  I/O  device  must  be  controlleo  by 
a system  process  to  provide  the  needed  I/O  capabilities. 
The  devices  that  will  be  controlled  by  system  processes  will 
be  the  card  reader*  the  card  punch*  central  site  printers* 
remote  printers  and  tape  drives. 

For  each  line  printer,  an  operator  (other  than  the  central 
site  operator)  will  always  be  in  attendance.  This  operator 
will  be  the  primary  "control ler"  of  the  line  printer.  The 
detailed  requirements  for  operating  local  and  remote  line 
printers  are  as  follows) 

1.  Ouring  operational  hours,  if  the  line  printer  is 
powered  on  and  the  system  is  running*  the  line  printer 
should  be  Kept  ousy  as  much  as  possible. 

2.  If  the  current  queue  being  processed  by  a line  printer 
is  exhausted,  another  queue  should  get  serviced 
automatically  (within  operational  constraints) . 
Separate  queues  will  be  Kept  for  each  cevice.  For  a 
given  device*  tne  queue  i requests  for  ary  level  should 
be  processed  before  the  queue  2 requests*  etc. 

3.  There  must  be  an  accountability  form  terminal 

associated  with  each  line  printer  (local  or  remote). 
Nothing  will  be  printed  or  the  line  printer  until  the 
controlling  process  ras  attached  the  terminal  bv 
soeclfic  action  on  the  oart  of  the  printer  operator. 
During  printer  operations*  there  will  be  one 

acc ountab i I 1 1 y form  producec  for  each  copy  of  each 
segment  printed  (one  Per  banner). 

4.  It  must  be  possible  for  a printer  operator  to  request  a 

sample  accountability  form  to  be  printed  on  the 

terminal  to  verify  proper  alignment  of  the  forms. 
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5.  It  Is  required  that  both  the  accountability  form 
terminal  and  the  line  printer  be  able  to  oetect  an  “out 
of  paper”  condition  ano  signal  this  cordltlor  to  the 
process  controlling  the  device* 

6.  It  must  be  possible  for  the  printer  operator  to  start 
and  stop  ooeratlon  of  the  line  printer. 

7.  The  printer  operator  must  also  be  able  to  restart  or 
reprint  requests  that  are  either  in  mlo-execut  lor  or 
that  have  oeen  processed  but  have  not  been  processed 
correc  1 1 y . 

8.  The  amount  of  communication  necessary  between  the 
printer  operator  and  the  central  site  operator  must  be 
Kept  to  a minimum. 

The  banner  for  all  printed  outout  must  identify  the 
classification  of  the  highest  level  of  data  that  can  be 
contained  in  the  printout. 

At  the  user’s  reauest*  page  headers  ana  footers  must  be 
supplied  on  each  page  of  printed  output  which  will 
Indicate  the  classification  level  of  the  segment  from 
which  the  printec  information  was  obtaineo.  The  header 
and  footer  labels  will  be  optional*  however  the  oefault 
will  be  to  orint  labels.  If  desired*  the  user  can 
replace  the  segment  classification  with  an  arbitrary 
string. 

11.  The  current  "heacer"  and  "destination"  options  will  be 
retained  for  distribution  pcint  information  only. 

12*  The  accountability  form  will  be  filled  in  with  alt 
pertinent  information  relative  to  the  request  that  it 
describes. 


A new  capability  must  be  supplied  to  allow  a system  process 
to  perform  taoe  I/O  based  on  user  reauests.  The  basic 
reauirements  for  handling  taoe  I/O  are  as  follcwsi 

1.  Only  system  processes  will  be  able  to  directly  attach 
tapes. 

2.  Normal  users  will  be  able  tc  place  a taoe  reao/write 
request  in  a queue  for  a system  process  to  perform  the 
actual  information  transfer. 
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3.  When  the  tape  data  is  online*  the  user  will  nave  to 
reference  the  data  as  a segment  or  mu  I 1 1 -segmen t file. 


I 


4.  Commands  must  be  provided  to  allow  users  to  maKe  taoe 
requests* 

5.  Tapes  must  only  be  mounteO  on  physical  drives  of  the 
same  “level**  as  the  tape. 

Modifications  must  be  made  to  the  present  card  input  scheme* 
The  basic  requirements  for  card  input  are  as  follomst 

1*  Only  system  processes  Mill  be  able  to  directly  attach 
the  card  reader. 

2.  The  operational  staff  must  not  be  burdened  Mith  the 
longterm  storage  ana  handlirg  of  a large  volume  of  card 
decks* 

3*  The  owner  of  a card  oeck  will  be  responsible  for 
identifying  the  classification  of  the  deck  at  the  time 
it  is  submitted  to  the  operations  staff  for  input. 

4.  A card  deck  submitted  for  input  will  be  read  into  an 
online  segment  having  the  same  c I ass  1 f ic it i on  as  the 
deck . 

The  standard  Multics  card  purching  capabilities,  which 
allows  queued  punch  requests  and  user  specified  punch  code, 
must  be  enhanced  to  identify  the  classification  of  the  data 
being  punched.  The  amount  of  card  punch  usage  is 
anticipated  to  be  low  enough  that  system  produced 
accountability  forms  are  not  required.  A combination  of 
administrative  Droceaures  and  system  software  should  be  used 
to  provide  a secure  method  of  clstributlng  classified  card 
decks. 


3.10.2  Design  Considerations 

The  message  segment  management  design  outlined  in  Section 
3.5  forces  the  design  away  from  the  current  Multics  queueing 
strategy.  For  each  device  type  supported  we  must  provide 
separate  queues  for  each  classification  level  suooortec  by 
the  system.  However,  unclassified  only  degenerates  to  the 
current  Multics  strategy. 


The  design  alternative  of  having  one  device  driver  tor  each 
permissible  "lever*  for  each  device  type  was  rejectee  due  to 
the  high  overhead  required  in  maintaining  several  “loic** 
driver  processes  and  in  having  the  I/O  coordinator  multiplex 
I/O  devices  and  accountability  f erm  terminals  between  driver 
processes. 
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3.10.3  Oesign  Approach 


The  approach  for  provialng  external  I/O  capabilities  is 
essentially  that  of  the  Hultics  standard  product*  i.e.  an 
I/O  coordinator  process  and  one  driver  process  per  device. 
For  each  device  type  supported  by  the  system*  there  Mill  be 
one  message  segment  queue  per  “level"  or*  if  desirec, 
several  queues  per  "level"  having  different  priority 
ratings.  The  I/O  coordinator  must  have  the  ability  to 
access  these  queues  at  all  "levels"  and  to  communicate  via 
IPC  Mlth  driver  processes  at  all  "levels."  The  driver 
processes  will  obey  the  standard  fixed  level  property  rules 
concerning  attachment  of  I/O  devices  and  segment  references. 


I/O  Coorairator 


There  is  no  “level"  at  which  the  I/O  coordinator  can  operate 
strictly  within  the  fixed  level  property  rules.  Therefore* 
it  will  operate  at  the  lowest  possible  "level"  with  the 
special  privileges  needed.  This  choice  offers  the  advantage 
of  not  requiring  special  IPC  privileges  for  the  driver 
processes  with  which  the  I/O  Coordinator  communicates.  The 
I/O  coordinator  will  have  the  following  characteristics  in 
the  two-level  security  environment* 

1.  There  will  be  multiple  queues*  specifically  one  per 
level  per  device  class  per  priority. 

2.  The  I/O  coordinator  will  allocate  tasks  to  various 
driver  processes  where  each  task  is  defined  as  a 
request  of  a single  user. 

3.  The  I/O  coordinator  will  be  responsible  fer  making  the 

decision  of  where  to  send  an  individual  task*  (i.e.  to 
the  appropriate  device  driver  process  at  the  correct 
"level").  The  decision  will  be  based  in  part  on  the 
minimum  expected  device  level  tor  a given  class  of 
device.  This  will*  for  example*  allow  the  I/O 
coordinator  to  allocate  all  tasks  for  a remote  line 
printer  to  a driver  process  at  "level"  n*  If  the  remote 
printer  is  never  to  be  classified  below  "level"  n.  At 
the  AFOSC  central  site,  where  printers  will  be  operated 
at  both  Secret  and  Top  Secret*  the  minimum  expected 
"level"  decision  criterion  will  prevent  requests  from 
Secret  users  and  below  belrg  sent  to  a Top  Secret 
device,  so  that  there  will  be  e minimum  of 

over-classification  at  distribution  time.  The  operator 
will  be  able  to  reconfigure  the  queues  by  changing  the 
minimum  exoected  "level"  for  a device  class. 
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4.  The  I/O  coordinator  Mill  rot  make  decisions  as  to  Mhich 
device  drivers  to  create.  This  Mill  be  cone  routinely 
by  the  system  operator  maruelly  loading  in  the  correct 
driver  at  the  correct  “level."  The  operator  Mill  also 
be  responsible  for  reclassifying  devices  Mhen 
necessary. 

5.  The  I/O  coordinator  Mill  have  to  oerfore  Interpretive 
security  operations  to  be  aDle  to  read  and  delete 
requests  from  each  message  segment  Queue  at  each 
“level"  in  the  system.  also,  the  I/O  coordinator  must 
perform  interprocess  communication  with  oriver 
processes  at  various  levels. 

6.  A temporary  history  file  wi  II  be  recordec  on  a per 
driver  basis  for  restarting  requests,  which  have 
abnormally  terminated  or  Mhich  Mere  sent  to  a printer 
that  had  no  paper. 

7.  The  I/O  Coordinator  will  be  responsible  for  deleting 

segments  when  reouested  by  a user.  This  task  cannot  be 
performed  by  the  driver  processes  since,  in  order  to 
allow  for  restarting,  a segment  cannot  be  deleted  until 
some  specified  length  of  time  after  printing.  Hence, 
the  I/O  Coordinator  must  bypass  the  fixed  level 

property  restrictions  in  order  to  delete  branches  from 
directories  of  all  classifications. 

8.  Part  of  the  optional  oata  supplied  by  a u«er  will  be  an 
event  channel  and  process  ID  which  can  be  usee  for  user 
notification  at  The  comoletion  of  his  request,  assuming 
that  the  process  is  still  active  at  the  tine  the 
reauest  is  processed. 

9.  The  devices  that  will  be  controlled  tnrouah  the  I/O 
coordinator  and  driver  processes  will  he  the  card 
reader,  tne  card  punch,  central  orirters,  remote 
printers,  and  tape  drives.  There  will  be  one  oriver 
process  for  each  incividual  device. 


L ine  Pr in  ters 


Both  local  and  remote  line  orirters  will  be  handled  r» 
printer  driver  processes.  Printer  driver  orocesses  wilt  t *» 
operated  with  the  following  constraints! 

1.  The  level  of  the  driver  wi  II  be  equal  to  the  levet  of 
the  device.  The  level  of  the  device  will  be  uveo  jr> 
determining  the  banner  classification  name  for  tne 
printed  output • 
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to  access  data  in 


2.  The  driver  process  Mill  be  passed  requests  generated 
from  various  ’’level"  user  processes  as  aeclcec  by  the 
I/O  coordinator. 


3*  The  driver  mill  aod  optional  header  and  footer 
labels  on  each  page  of  output  indicating  the  level  of 
the  segment  being  printed.  This  Mill  be  explained  in 
more  detail  later. 


4.  The  printer  driver  process  Mill  be  responsible  for 
interpreting  the  “need  to  Krox"  access  of  the  requestor 
from  the  access  control  list  of  the  segment  that  is 
being  printed  (The  I/O  coordinator  Mill  interpret  the 
user’s  access  for  deleting*  Mhen  reauesteo.l 

5.  The  driver  process  Mill  require  an  accountability  form 
terminal  to  be  attached.  At  no  time  Mill  the  driver 
process  attach  its  printer  before  the  attachment  of  the 
terminal.  If  tne  terminal  is  inoperative*  the  orinter 
is  also  assumed  to  be  inoperative. 

6.  The  driver  process  Mill  be  modified  to  prepare 
accountability  forms. 

7.  There  Mill  be  a sequence  number  associated  with  each 
banner  sheet  to  help  operations  burst  the  printer 
output.  Since  this  number  Mill  be  generated  by  a 
driver  orocess  at  request  processing  time*  it  Mill  be 
unknown  to  the  user.  Therefore,  it  cannot  be  usea  cS  a 
claim  check  to  pick  up  printed  output. 


8.  Driver  processes  will  accept  commands  from  the 
accountability  form  terminal.  These  commands  will  bel 


start  start  printing  requests 

stop  stop  at  next  request 

abort  stop  immediately 

sample  print  sample  term 


When  the  printer  operator  types  ’’sample**  on  the 
terminal.  the  driver  process  will  produce  one  sample 
accountability  form  to  verify  alignment  of  the  paper. 
However,  it  will  not  start  producing  outout  until  the 
operator  enters  the  start  command. 


9.  The  driver  process  will  prepare  an  accounting  file  to 
charge  eacn  user  for  the  use  of  the  printer. 


Printer  output  Mill  have  a banner*  optional  pas*  labels*  and 
an  accountability  fore  to  help  identify  the  classification 
of  the  printed  inforaatlon.  The  banner  will  have  an  aoded 
field  of  large  block  lettering  to  indicate  that  the  printed 
output  **eay  contain  <level>aa  where  <level>  is  the 
classification  level  (without  the  category  set)  of  the 
device  on  which  the  inforeation  was  printed.  The  enewcnic 
used  in  the  banner  aust  be  no  longer  than  thirteen 
characters.  (The  sane  anemonics  will  be  used  throughout  the 
systen.)  The  classification  on  the  banner  cannot  be 
controlled  by  the  user  and  will  be  the  same  as  that 
indicated  on  the  accountability  form.  In  addition  to 
printing  the  classification  level  in  large  block  letters* 
the  full  classification*  including  categories*  will  be 
printed  in  standard-size  letters. 

The  header  and  destination  options  to  the  aprint  command 
will  still  operate  as  in  the  standard  Hultlcs  system. 
However*  the  information  supplied  in  this  manner  must  not  be 
used  to  determine  classification  of  output.  Rather,  the 
information  should  be  considered  as  user  delegated  “need  to 
know"  author i zation  to  be  used  to  help  in  the  distribution 
of  output. 

Header  and  footer  page  labels  may  be  placed  on  each  page  of 
printed  output  by  use  of  a new  dprlnt  option.  (The  default 
will  be  no  page  labels.)  The  optional  label  will  contain 
the  classification  of  the  segment  from  which  the  i nf crmat ion 
was  obtained.  Alternatively*  a user  may  request  that  an 
arbitrary  string  (less  than  132  characters)  be  used  in  dace 
of  the  segment  classification  by  using  another  new  option  to 
the  dprlnt  command.  Header  ana  footer  oage  labels  will  oe 
centered  across  the  page.  It  should  be  recognized  that  the 
use  of  page  labels  will  recuce  the  number  of  text  lines  per 
page*  and  hence*  may  upset  the  page  aligrment  of  formatted 
output . 


Tapes 


Tapes  will  be  handled  as  part  of  the  general  I/O  scheme 
mentioned  above.  The  "level"  of  a tape  driver  process  will 
always  equal  the  "level"  of  the  requests  which  it  hardies. 
A tape  driver  process  will  be  permitted  read/write  access  to 
tapes  having  the  same  "level"  and  read-only  access  to  tapes 
of  a lower  “level."  Krite-only  access  to  higher  level  tapes 
will  not  be  permitted  since  there  is  no  apparent  value  In 
such  a capability. 


The  user  interface  to  the  tape  I/O  mechanism  will  permit  the 
user  to  request  that  a tape  be  read  into  a segment  or  that  a 
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segment  be  written  to  tape*  The  user  nay  optionally  request 
notification  (oy  means  of  an  I PC  makeup)  of  the  completion 
of  a tape  read  operation*  The  user  need  not  specify 
"standard"  or  "non-standara"  tape  format  since  this 

information  mill  be  available  in  the  tape  cescriptor 

segment.  Tape  drivers  will  operate  as  follows) 

i*  The  “level"  of  the  tape  driver  process  mill  be  the  same 

as  the  "level“  of  the  requestor.  However*  only  Secret 

and  Top  Secret  processes  mi  II  be  used  at  AFOSC. 

Z«  The  “level"  of  the  tape  drive  that  mill  be  chosen  to 

satisfy  a given  tape  request  mill  be  the  same  as  the 

"level"  of  the  tape  as  indicated  by  the  tape  oescrlotor 
segment.  (The  operator*  however*  is  the  primary 
control  that  the  "level"  of  the  drive  matches  the 
"level"  of  the  reel,) 

3.  If  the  level  of  the  driver  process  is  greater  than  the 
“level"  of  the  tape  drive*  the  attachmert  mill  be  read 
only. 

<*.  Tape  driver  processes  mill  operate  within  the  fixed 
level  property  restrict  ions . Therefore*  any  segments 
created  while  reading  tapes  mill  have  the  same  “level" 
as  the  driver  process. 

5.  The  access  mode  given  to  the  requestor  for  a read 
request  will  be  the  minimum  of  the  requested  mode  of 
access  and  the  effective  moce  of  access  for  that  user 
to  the  tape  descriptor  segvent. 

6.  On  a read  tape  request*  the  information  will  be  stored 
in  a mu  1 1 i -segment  file  in  a tape  pool  directory  of  the 
correct  level  using  the  taoe  number  as  the  segment  rame 
(unless  another  pathname  was  specified  by  t*e  user). 

7.  Storage  management  of  the  tape  pool  directories  will  be 
a problem.  A taoe  image  segment  or  mu  I tl -segmen t file 
(which  can  occupy  thousanos  of  pages  of  online  storage) 
must  remain  in  its  tape  pcol  directory  long  enough  to 
be  processed  by  the  user.  The  required  retention  time 
will,  of  course*  vary  from  one  tape  segment  to  the 
next.  In  oroer  to  allow  the  user  to  aid  in  storage 
management,  a "oelete"  option  will  be  provided  for  the 
tape  write  request.  If  specified*  this  option  mill 
inform  the  taoe  driver  process  to  delete  a segment 
after  writing  it  to  tape.  As  a further  aid  in  storage 
management,  it  may  also  be  desirable  to  give  users 
modify  oermlssion  in  an  inner  ring  to  the  taoe  cool 
directories.  A command  could  then  be  orovioea  which 
deleted  a tape  segment  at  the  user's  request  while 
operating  in  an  inner  ring.  This  would  ensure  that  a 
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user  could  only  delete  Ms  cwn  tape  segments*  and  could 
properly  handle  the  case  of  shared  tape  segments. 
Periodically*  it  will  be  necessary  to  delete  from  the 
tape  pool  directories  these  segments  which  have 
exceeded  a specified  age  limit. 

8.  The  “Multlcs  standard  tape"  information  stored  in  the 
tape  descriptor  segment  will  be  used  to  identify  which 
device  interface  module  the  driver  process  will  use  to 
read/write  the  tape.  This  provides  o means  of 
automatically  handling  both  Multlcs  standard  format 
tapes  and  non-standard  format  tapes  through  the  same 
user  Interface. 

9.  A tape  write  request  will  write  whole  tapes  only.  A 
tape  read  request  may  read  a whole  tape  or  else  may 
specify  a portion  of  a tape  by  supplying  two 

j end-of-fllj  marks  at  which  to  start  ana  stop  reeding. 

Individual  records  will  net  be  read  or  replaced  on  a 

| tape. 

j 10.  The  user  will  oe  able  to  specify  the  pathname  to  be 

j used  for  the  read/write  operation  if  he  wants  to  use  a 

different  segment  than  woulc  be  provided  in  the  face 
^ pool  directory. 

S Note*  The  user  must  have  enough  quota  to  hold  an  entire 

J tape  if  ne  wants  to  read  a tape  using  a specified 

pathname. 


Card  Incut 
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Card  input  will  be  handed  much  the  same  as  in  the  present 
system.  A user  will  submit  his  card  deck  to  the  operations 
staff  along  with  a special  contrcl  card  specifying  a useric. 
The  aeck  will  then  be  read  into  a segment  created  In  a card 
pool  directory,  and  the  specified  userid  will  be  acoeo  to 
the  access  control  list  of  the  segment.  There  will  actually 
be  one  card  pool  directory  per  "level."  The  owner  of  a oeck 
will  be  responsible  for  identifying  the  classification  of 
his  deck  and  thus  the  appropriate  card  pool  directory. 
Unlike  the  present  scheme,  no  link  to  the  card  image  segment 
will  be  created  for  the  user.  This  eliminates  a 
vulnerability  of  the  present  card  lnout  mechanism  whereby  a 
user  coulo  cause  a link  to  be  placed  anywhere  in  the 
hierarchy.  Instead*  the  user  will  be  given  a sequence 
number  by  which  to  identify  the  card  image  segment  created 
for  his  deck.  When  logged  in,  the  user  will  employ  a new 
command  which  takes  the  sequence  number  as  an  argument. 


locates  the  associated  card  image  segment*  copies  It  into  a 
new  segment  named  by  the  user*  and  then  deletes  the  card 
Image  segment.  This  new  command  will  operate  In  an  Irner 
ring.  Users  will  have  no  access  to  card  Image  segments  or 
card  pool  directories  in  ring  4.  Periodical ly,  it  Mill  be 
necessary  to  delete  from  the  card  pool  directories  those 
segments  which  have  not  been  copied  and  deletec  within  a 
reasonable  period  of  time. 


Card  Output 


Card  output  presents  a new  problem  in  iaentifyirg  the 
classification  of  the  information  punched  on  the  deck. 
Printed  output  is  initially  in  one  piece  and  each  page  can 
be  labeled.  Card  decks.  however.  are  not  connected  and 
cannot  be  labeled  by  the  system  except  for  deck  header  and 
trailer  cards.  Therefore,  it  is  easy  for  caro  decks  to  get 
mixed  with  other  cards  of  different  classifications  unless  a 
new  procedure  is  adooted. 

The  obvious  solution  is  to  use  cards  of  different  colors  for 
the  different  deck  classifications.  This  solution  carries 
with  it  some  operational  problems  which  must  oe  mentionec. 

First,  for  this  system  to  be  effective,  a giver  card  color 
must  always  be  usea  to  identity  the  same  classification. 
This  is  needed  To  ensure  correct  handling  of  the  decks  ov 
the  distribution  staff  and  operations  personnel.  Therefore, 
if  the  supply  of  cards  for  a given  color  is  exhausted,  all 
card  output  tor  that  classification  must  be  suspended. 

Second,  a card  deck  of  a given  color  Is  difficult  to 
declassify  since  the  meaning  of  the  color  must  be  preservec. 
Therefore,  the  downgrading  of  a card  deck  must  be  oone  by 
repunching  the  entire  deck  on  cards  of  a different  color  and 
destroying  the  original.  This  operation  must  be 
administratively  forbidden  except  under  carefully  controlled 
conditions  and  only  when  approved  by  the  System  Security 
Officer. 

Third,  to  avoid  the  problems  of  over-classification,  the 
punch  must  be  handling  requests  of  only  one  c I ass i f i ca t i on 
during  any  period  of  time.  This  means  that  operator 
intervention  is  necessary  every  time  a request  aueue  of  a 
different  •’level**  is  td  be  serviced. 

The  Multics  punch  driver  process  will  be  modified  to  support 
this  mode  of  operation  by  the  following  software 
capabilities  and  administrative  procedures! 
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1.  The  punch  driver  process  will  operate  within  the  fixed 
level  property  restrictions  for  access  to  segments  and 
I/O  channels. 

2.  To  prevent  over-classification  of  punched  output.  the 

driver  process  should  operate  at  the  "level"  of  the 
requesting  process  rather  than  at  a higher  “level." 
Also  the  "level"  of  the  card  punch  should  be  the  same 
as  the  "level"  of  the  driver  process.  This  will  ensure 
that  tne  color  of  the  card  deck  will  indicate  the 
classification  which  corresponds  to  the  clearance  of 
the  requestor.  The  I/O  coordinator  will  help  to 

separate  the  data  of  different  request  "levels"  through 
the  "minimum  expected  level"  decision  mechanism 
described  above.  Only  if  the  operational  buraen  of 
downgrading  a portion  of  the  seeks  punched  is 

acceptable,  should  the  "minimum  level"  of  the  punch  be 
set  higher  than  unclassified. 

3.  The  I/O  coordinator  will  inform  the  operator  when  the 
queue  of  requests  for  the  current  aevice  driver  is 
empty,  to  allow  him  to  reclassify  the  device  for 
operation  at  a new  "level." 

4.  An  operator  will  change  the  operating  "level"  of  a 
punch  driver  byl 

logging  out  the  driver  process. 

reclassifying  tne  punch  to  the  new  "level"? 

changing  the  color  of  the  card  supply? 

logging  in  a punch  driver  of  the  correct  "level." 

The  driver  process  will  inform  the  I/O  coordinator  of 
its  clearance  which  will  be  used  in  routing  use1* 
requests.  However,  the  security  of  the  punched  output 
is  totally  dependent  upon  the  correct  card  color  being 
loaded  by  the  operator. 

5.  Accountability  forms  for  the  card  decks  will  have  to  be 
prepared  manually.  The  normal  terminal  output  of  the 
driver  can  be  used  to  separate  the  decks  to  ensure  a 
one  to  one  corresponoence  between  accountability  ferms 
and  card  decks. 

6.  Users  should  oe  discouraged,  administratively.  from 
requesting  a crunch  of  a segment  which  has  a 
classification  wnich  is  lower  than  the  clearance  of  his 
process.  This  wou I a result  in  implicitly  upgrading  tre 
information,  resulting  in  overclassification. 
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7m  Tr>e  information  provioed  by  the  terminal  cutout  of  the 
driver  process  Mill  be  stored  in  a segment  to  proviae 
sn  online  audit  of  completed  punch  requests* 
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v 

I 

I 

i 

1 

t 


• j 

> i 
' l 


3.11*1  Description 

The  system  control  orocess  performs  the  tasks  of  system 
Initialization,  answering  service  and  system  control. 

In  its  function  as  the  system  initialization  process*  it 
reads  a system  bootstrap  tape  and  creates  the  Multics 
environment.  If  necessary,  the  system  control  process  is 
used  to  reload  the  file  hierarchy  from  backup  tapes. 

In  its  function  as  the  answering  service  orocess,  it 
"listens"  to  all  teletype  channels.  When  a terminal 
oowers-on,  it  sands  an  Interrupt  to  the  system  control 
process.  The  answering  service  then  prints  a greeting,  and 
validates  the  ‘ogin  or  diai  command.  In  the  case  of  a vslld 
login  command,  the  answering  service  creates  c orocess  in 
the  name  of  the  user,  allocates  the  console  I/D  channel  to 
the  process,  and  sends  the  process  a makeup.  The  answering 
service  also  handles  reauests  from  the  user's  process  for 
new_proc  and  logout,  ana  coordinates  requests  for  table 
updates  from  the  System  administrator  ana  Project 
Adminl strators . 

In  its  function  as  tne  system  control  process,  it  recorcs 
accounting  information,  valioates  requests  for  I/O  devices 
(tapes,  etc.),  controls  the  consoleless  daemons,  and 
provides  an  operator  command  interface. 


3.11.2  Requirements 


It  is  a requirement  that  these  functions  continue  to  work, 
without  substantial  implementation  modifications. 


% 


It  is  a requirement  that  the  system  control  process  violate 
the  fixed  level  property  as  little  as  possible. 


3-11.3  Chosen  Approach 

To  minimize  the  need  for  special  access  and  the  necessity  to 
rewrite  code*  the  system  control  process  will  run  at  the 
unclassified  level.  In  this  way*  all  System  Administration 
segments  (e.g.  user  registration  and  accounting)  will  be 
unclassified.  Thus*  System  Administration  and  Project 
Administration  will  be  unclassified  for  nearly  all  functions 
and  will  require  no  violations  of  the  fixed  level  property. 
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IPC  (interprocess  communication)  will  be  modified  to  provice 
the  necessary  communication  paths  between  the  system  control 
process  and  user  processes.  IPC  will  have  a privileged 
entry  to  set  a flag  which  will  allow  the  system  control 
process  to  receive  messages  from  any  “level"  process, 
despite  the  fact  that  it  is  unclassified.  By  normal  access 
rules  it  will  always  be  able  to  send  IPC  messages  to  any 
process,  (see  Section  3.5) 

In  communicating  with  other  processes*  the  system  control 
process  will  be  able  to  use  specified  message  segments  of 
any  “level."  (see  Section  3.9) 


The  system  control  process*  in  its  function  as  the  system 
initializer*  will  initialize  the  ring  0 tables  used  to 
validate  all  attachments  of  I/O  channels.  (See  Section 

3 * S . ) 
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As  part  of  its  function  as  the  system  control  process.  it 
will  execute  ooerator  commands  for  reclassifying  I/O 
channels*  handling  tapes*  etc. 


See  Section  3.3  for  an  explanation 
validation  procedures. 


of  absentee  and  login 


See  Section  3«i3  for  an  explanation 
System  Control  Process  in  reloading. 


of  the  role  of  the 
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3.12  OTHER  SYSTEH  PROCESSES 


3.12*1  The  Backup  and  Oumper  Daemons 
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Two  system  daemons,  namely  "Backup**  and  "Dumper,"  are 
employed  to  perform  file  system  backup.  These  two  caeirons 
scan  the  hierarchy  and  copy  to  tape  "eligible"  files  and 
directories.  The  eligibility  of  a file  or  directory  for 
backup  dumping  depends  upon  the  dumping  mode.  Incremental 
dumps,  performed  by  the  backup  daemon,  dump  files  and 
directories  which  have  been  mocified  since  they  were  last 
incrementally  dumped.  Complete  dumps,  performed  (less 
frequently)  by  the  dumper  daemon,  dump  all  files  and 
directories. 


i 

i 
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In  the  past,  two  separate  daeeons  were  needed  in  order  to 
run  incremental  and  complete  domes  concurrently.  However,  a 
multiple  login  feature  is  now  available  which  permits  a user 
(or  daemon)  to  be  logged  in  several  times  concurrently  with 
the  same  principal  identifier.  Hence,  it  is  feasible  to 
have  only  a single  daemon  for  backup  purposes.  Therefore, 
Dumper. SysOaemon  will  be  discarded  in  order  to  minimize  the 
number  of  system  daemons  ard  to  simplify  the  access 
requirements  for  file  backup. 

The  backup  daemon  will  run  with  the  highest  clearance  level 
so  that  it  may  read  all  files  and  directories.  This 
implies,  of  course,  that  backup  tapes  and  dump  maps  will,  as 
desired,  have  the  highest  classification.  The  backup 
daemon,  being  a trusted  process,  will  be  permitted  to 
directly  attach  tapes. 


The  backup  daemon  must  set  the  date-time  dumped  (dtd)  for 
all  segments  and  directories.  Currently,  modify  permission 
on  a directory  is  needed  to  set  dtd  for  branches  contained 
within  the  directory.  This  implies  that  the  backup  daemon 
would  need  the  ability  to  modify  directories  at  all  levels. 
This  problem  is  really  a manifestation  of  a more  basic 
problem.  Intuitively,  it  makes  little  sense  that  a user  is 
forced  to  give  the  backup  caemon  modify  permission  to 
directories.  The  function  of  backup  is  essentially  "reed 
only"  in  nature.  Therefore,  read  access  to  a segment  will 
be  sufficient  to  set  otd  for  that  segment. 
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The  date-time  dumped  (otd),  date-time  modified  (dtm), 
date-time  used  (dtu),  ana  aate-time  entry  modified  (dte») 
segment  attributes  mill  no  longer  be  subject  to  explicit 
modification  by  users*  Currently*  these  date-times  are 
Mrlteable  via  hcs_  and  hence  are  not  trustworthy. 
Therefore*  hcs_  entries  which  set  these  date-times  will  be 
removed* 


Certain  changes  to  the  aumper  program  (used  by  the  backup 
daemon)  will  be  required*  First*  the  new  I eve  I /cate  sory 
information  must  be  backed  up  and  hence  must  be  added  to  the 
dump  record  format*  Second*  a new  hphcs_  call  must  be 
provided  to  permit  the  backup  daemon  to  set  oto.  And  third, 
a new  branch  attribute  called  the  date-time  subtree  moolfled 
(see  Section  3*7*5)  must  be  introduced  to  guide  incremental 
dumping. 

The  backup  daemon  will  not  violate  the  fixed  level  crcoerty 
rules  in  any  manner. 


3*12.2  The  Retriever  Daemon 
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The  retriever  daemon  is  used  to  recover  selected  files  and 
directories  from  backup  tapes  at  the  user’s  reauest.  In 
order  to  read  backup  tapes*  the  retriever  must  run  with  the 
highest  clearance* 

The  retriever  will  require  certain  special  privileges.  In 
order  to  restore  files  and  directories  to  the  hierarchy*  the 
retriever  must  be  able  to  create  branches  of  all 
classifications  and  to  modify  segments  and  olractorits  of 
all  classifications. 

Certain  modifications  to  the  retriever  program  will  be 
required.  New  ring  0 calls  must  be  inserted  to  properly 
restore  the  classifications  of  segments  and  directories. 
Also,  a new  hohcs_  primitive  will  be  provided  to  il lo*  The 
retriever  to  restore  the  various  date-times  (since  these 
will  no  longer  be  writeable  via  hcs_  as  described  above). 

It  is  possible*  although  very  unlikely*  that  an  attempt 
could  be  made  to  retrieve  a branch  into  a directory  of  a 
higher  classification  in  violation  of  the  non-decreasing 
classification  rule  of  the  hierarchy.  This  could  only  occur 
if  a directory  were  created*  deleted*  and  then  recreated  at 
a higher  classification.  (This  sequence  could  also  be 
simulated  simply  by  swapping  directory  names.)  Ring  a will 
refuse  to  set  the  classification  of  a branch  lower  than  the 
classification  of  its  containing  directory.  Hence,  an 
attempt  to  retrieve  a branch  into  a directory  of  higher 
classification  will  implicitly  reclassify  the  branch  et  the 
level  of  the  directory.  If  a user  wishes  to  avoid  such 
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reclassification,  he  can  rename  or  delete  the  existing 
directory,  or  else  can  retrieve  the  branch  into  a different 
directory  (as  described  below) • 


It  is  also  possible,  but  unlikely,  tnat  an  attempt  could  be 
aade  to  retrieve  a segment  into  a directory  of  lower 
classification.  This  could  only  occur  if  a di-ectory  were 
created,  deleted,  and  then  recreated  at  a lower 
classification.  Oue  to  the  quota  oroblem  (see  Section 
3.7.4),  segments  are  required  to  have  the  same 
classification  as  their  containing  directory.  Therefore, 
ring  0 will  refuse  to  set  the  c I asslf  icatlor  of  a segment 
branch  higher  than  that  of  its  containing  directory.  Since 
the  retriever  cannot  be  permitted  to  declassify  a segwent,  a 
request  to  retrieve  a segment  into  a directory  of  lower 
classification  must  be  rejectee.  A user  can  avoio  this 
problem  by  renaming  or  deleting  the  existing  directory  or  by 
retrieving  into  a different  directory. 

The  SSO  must  develop  a plan  to  administer  the  submission  ard 
validation  of  retrieval  requests.  Clearly,  users  cannot  be 
permitted  to  directly  inspect  dump  mans.  This 
r espons ib i 1 1 1 y shoula  probably  be  given  to  the  SSO  or  his 
assistant.  Retrieval  requests  can  be  submitter  in  person  so 
that  the  requestor's  ioentity  can  be  valiaatec.  Once  the 
requestor's  identity  is  known,  some  set  of  rules  must  be 
applied  to  determine  the  legitimacy  of  the  request.  Some 
alternatives  includei 


1.  A user  can  retrieve  anything  under  his  home  directory. 
A Project  Administrator  can  retrieve  anything  under  his 
project  directory.  A System  Administrator  can  retrieve 
anything. 


2.  A user  must  have  write  access  to  the  segment  if  it 
exists  online.  Otherwise,  he  must  have  mooify 
permission  for  the  nearest  superior  directory  which 
exists  online.  These  checks  can  be  made  by  the  SSC  or 
his  assistant.  (Note  that  under  this  scheme,  granting 
access  to  a segment  implies  granting  access  to  tte 
entire  backup  history  of  the  segment.  This  shoula  not 
be  much  of  a oroblem,  however,  since  segments  are 
rarely  “reused'*  for  different  ourooses.) 

Once  a user's  right  to  retrieve  a segment  or  alrectory  has 
been  established,  he  can  then  retrieve  that  segment  or 
directory  into  any  existing  directory  in  the  hierarchy  for 
which  he  has  apoend  permission.  In  most  cases,  a segment  or 
directory  will  be  restored  to  its  original  position  within 
the  hierarchy.  In  some  cases,  however,  a user  may  request 
that  a segment  or  directory  be  placed  in  a new  position 
within  the  hierarchy.  This  is  known  as  a “cross-directory” 
retr ieval . 
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It  may  also  be  desirable  to  acceot  retrieval  requests  from 
remote  locations.  No  formal  mechanism  currently  exists  for 
this  purpose*  In  current  oract  ice,  retrieval  requests  are 
sometimes  accepted  over  the  telephone.  It  should  be  noted 
that  retrievals  cannot  be  used  in  any  manner  whatsoever  to 
declassify  information.  Hence*  telephone-requested 
retrievals  can  be  performed  without  fear  of  such  a security 
breach.  However*  sabotage  is  possible  by  simply  overwriting 
online  segments  witn  backup  copies.  Also*  reed  to  Knew 
access  can  be  compromised  by  a cross- dl rec t cry  retrieval. 
Therefore*  positive  user  identification  shoulc  at  least  be 
required  for  all  cross-directory  retrievals*  as  well  as  for 
all  retrievals  outside  of  >udd. 


3*12.3  The  Repair  and  R in g_ l_Pepa ir  Daemons 

Two  daemons*  namely  "Repair**  and  "Ring_i_Repalr are  usei 
to  perform  emergency  fixes  to  the  system.  The  Ring_i_Repa ir 
daemon  runs  in  ring  one  in  oroer  to  handle  special  rirg  ore 
problems*  e.g.  the  installatior  of  a ring  one  gate.  Potn 
daemons  require  essentially  unlimited  access  to  the  system 
via  Dhcs_  and  hohcs_.  The  retain  daemons  sroul a run  at 
system  high,  since  they  have  access  to  all  information  in 
the  system.  They  may  have  to  “write  down**  information  on 
occasion. 

The  passwords  for  tnese  daemons  should  be  Known  only  to  tre 
SSO  and  should  be  changed  after  each  logout.  At  his 
discretion,  the  SSO  will  maKe  tne  oassworcs  available  to 
system  programmers  ano  other  persons  needing  to  use  the 
repair  daemons.  It  may  be  desirable  for  tne  system  to 
actually  require  a password  chanie  for  tnese  daemons 
(performed  by  the  SSO  between  each  logout  ard  next  login. 


3.12.4  The  Metering  Daemon 

The  Metering  aaeaon  is  useo  to  generate  system  performance 
graphs  and  other  system  meters.  For  this  purpose,  phcs_ 
access  is  required.  The  daemon  probably  shoulc  run  system 
high,  because  the  metering  information  may  be  an  lnfcrmatlcn 
channe I . 


3*12.5  The  Prlnt_Oump  Daemon 

The  Print_Oump  daemon  is  sometimes  emoloyeo  to  orint  BOS 
dumps  (see  Section  3.13.1)  during  normal  Multics  ooeratlor. 
A 80S  dump  may  reside  either  on  tape  or  in  a soeclal  area  of 
online  storage  known  as  the  OUMP  partition.  At  system 
initialization  time,  the  initializer  copies  dumps  from  the 
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CRASH  RECOVERY 


3.13.1  BOS 

BOS  (Bootload  Operating  System)  is  a collection  of  programs 
used  to  perform  a number  of  basic  functions  such  as  loaolrq 
a Mu  I tics  system  tape,  assisting  in  Nultlcs  shutdown,  ard 
dumping  the  Multics  machine  l wage  (usually  following  a 
system  crash).  BOS  also  plays  a significant  role  in  file 
system  backup  and  recovery  operations.  Per iocica I I y , 
Multics  is  shut  down  so  that  BOS  may  oerform  a “SAVE."  A 
SAVE  essentially  copies  all  of  online  storage  onto  tape, 
thus  establishing  a checkpoint  for  use  in  file  system 
recovery.  In  the  event  of  online  storage  loss,  BOS  is 
called  upon  to  perform  a "RESTOR,"  l.e.  the  loading  of 
online  storage  from  SAVE  tapes. 

BOS  will  have  no  knowledge  of  Multics  security  controls. 
Operational  control  of  BOS  is  sufficient  to  ensure  security. 

BOS  dumps  of  tne  Multics  machine  image  may  contain 
information  of  ill  classifications  and  hence  will  be  treated 
as  Top  Secret.  QOS  itself  will  provide  neither  security 
banners  nor  page  labels  for  printed  output.  To  do  so  wculd 
add  unwanted  complexity  to  BOS,  and  would  require  that 
specific  classification  names,  e.g.  "Top  Secret,"  be 
included  directly  in  BOS  programs.  Since  such  names  are 
Intended  to  be  installation  parameters,  a different  version 
of  BOS  would  be  required  for  every  installation. 

BOS  dumps  may  be  immediately  directed  to  a printer,  or  else 
may  be  saved  on  tape  or  disk  for  later  printing.  In  the 
former  case,  it  is  recommended  that  soeclal  paper  be  usee  to 
indicate  the  classification  of  the  printed  output,  e.c. 
paper  having  a “Top  Secret"  water  mark.  If  BOS  dumps  are 
printed  during  normal  Multics  operation,  banners  ana  page 
labels  can  be  added  at  that  time. 

3.13.2  The  Salvager 


The  salvager  is  a group  of  programs  desigrea  to  detect, 
report,  and  correct  wherever  possible  any  incons istenc les  in 
the  Multics  directory  hierarchy.  The  salvager  runs  within  a 
special  version  of  the  Multics  operating  system  ana  utilizes 
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a separata  partition  of  online  storage.  The  salvager  is 
eaployea  following  either  a normal  Multlcs  shutdown  or  an 
emergency  shutdown  instigated  by  a system  crash. 


i 

P > 

F <\ 


The  salvager  will  be  Knowledgeable  of  security  controls  as 
they  apply  to  the  file  system.  The  only  Kinds  of 
secur 1 ty-re I ated  Inconsistencies  which  can  be  detected  by 
the  salvager  are  violations  of  the  ron-oecreasirg 
classification  rule  of  the  hierarchy.  Unfortunstel y * 
however*  such  inconsistencies  cannot  be  autoaat  lea  I I y 
corrected.  If  an  unclassified  directory  is  discovered  below 
a Secret  directory*  it  does  not  seem  warranted  to  oelete  the 
unclassified  directory.  It  seems  more  reasonable  perhaps  to 
upgrade  the  directory  and  its  inferiors  where  necessary 
since  this  cannot  compromise  security.  however*  this 
strategy  may  produce  absurd  results  if*  for  example*  >uad 
became  erroneously  classified  Secret  due  to  a system  crash. 
Therefore*  the  salvager  will  mark  a branch  "out  of  service" 
whenever  it  fails  to  comply  with  security  regulations.  The 
pathnames  of  such  branches  will  be  reported  to  the  operator. 
Explicit  action  by  the  SSO  will  be  required  after  the  system 
has  been  restarted  to  place  these  branches  bach  in  service. 

The  running  of  the  salvager  will  be  enforced  by  the  system. 
Currently,  when  Muitics  is  bootloaded  without  prior 
salvaging,  a warning  message  is  printed  for  the  ooerator. 
Instead  of  lust  a warning,  system  lnit  ia  I i rati  on  will 
actually  be  aborted. 


> 

( 


! 
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There  exist  four  different  salvaging  modes  Known  as  fast, 
active*  regular*  and  long.  A fast  salvage  merely  flushes 
the  paging  device.  In  current  practice,  a fast  salvage  is 
usually  performed  after  a successful  emergency  shutdown. 

When  shutaown  succeeds  in  recovering  the  file  system  device 

configuration  table  (FSOCT)  from  core,  but  fails  to 

deactivate  all  active  segments*  an  active  salvage  is 

sometimes  performed.  An  active  salvage  examines  all 

directories  which  could  not  be  deactivated.  If  a shutaown 

attempt  falls  to  recover  the  FSOCT  from  core*  then  a regular 

salvage  is  performed.  Only  a regular  salvage  will  examine 

all  directories  and  completely  rebuild  the  FSOCT.  Hence, 

only  a regular  salvage  is  guaranteed  to  detect  all  possible 

reused  addresses,  i.e.  pages  claimed  by  more  than  one 

segment.  To  avoid  possible  security  violations*  such  pages 

are  zeroed  by  the  salvager.  A I on  j salvage  is  basically  the 

same  as  a regular  salvage  except  that  it  rebullos  all 

directories  (not  Just  inconsistent  directories)  for  tne  *" 

purpose  of  directory  compaction.  It  is  recommended  that 

regular  or  long  salvaging  always  be  performed  so  as  to 

ensure  file  system  consistency.  (For  the  oresert  MIT  » 

hierarchy,  a regular  salvage  requires  about  ten  minutes  to 

run.  Therefore*  the  time  saveo  by  use  of  the  fast  or  active 

salvage  modes  is  negligible.  However*  it  is  expected  that 
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the  time  to  perform  a regular  salvage  Mill  increase 
approximately  linearly  with  the  number  of  branches  in  the 
hierarchy . I 

As  Mith  80S*  the  salvager  Milt  provide  neither  security 
banners  nor  page  labels  for  printed  output.  Special  Top 
Secret  paper  can  be  usea  as  suggested  for  BOS  output. 


3«13,3  Reloading 

RoJIoMlng  a system  failure  Mh  lch  causes  extensive  file 
system  damage*  it  is  necessary  to  recover  the  former 
contents  of  online  storage  from  SAVE  tapes  and  backup  tapes. 
This  recovery  operation  is  knoxn  as  a RESTOR/re I oac.  The 
first  step  in  the  recovery  procedure  is  to  use  BOS  to 
perform  a RESTOR  of  the  latest  SAVE.  Next,  Multics  is 
bootloaoed  and  backup  tapes  produced  subsequent  to  the 
latest  SAVE  are  reloaoed  in  chroro I oglca I order.  Thus,  the 
hierarchy  is  restored  to  its  state  at  the  time  of  the  latest 
Incremental  dump. 

The  reloading  of  the  file  system  fro*  backup  tapes  is 
presently  performed  by  the  initializer.  The  reason  for 
choosing  the  initializer  is  because  other  daemons  carrot  te 
logged  in  until  the  answering  service  begins  operation.  The 
answer ing  service,  in  turn,  cannot  be  started  until  all  cf 
its  data  bases  have  been  reloaoed. 

When  performing  reloading,  the  initializer  Mill  require 
certain  special  privileges.  First,  as  an  unclassified 
process,  it  must  be  permitted  to  read  Top  Secret  backuo 
tapes.  Second,  it  must  be  capable  of  creating  branches  at 
all  levels  and  Mriting  at  all  levels.  But  as  with  the 
retriever,  the  initializer  is  forbidden  to  violate  the 
increasing  cl  ass  1 f ic a t ion  rule  of  the  hierarchy. 

The  reloader  and  the  retriever  programs  share  many  of  the 
same  modules.  Hence,  the  program  modifications  and  tne 
security  cons i derat i ons  ciscussed  in  Section  3.12.?  apply  to 
reloading  as  Mel  I as  retrieving.  It  should  be  emphasized 
again  that  reloading,  like  retrieving,  mill  never  ceclassify 
information. 

There  exists  another  type  ot  reload  Known  as  a "cold  reloac" 
Mhich  is  not  generally  usea  as  a method  of  crash  recovery, 
but  is  sometimes  used  for  special  purposes  such  as  directory 
reformatting.  To  facilitate  major  operations  of  this  type, 
a complete  dump  is  usually  performed  immediately  before  i 
cold  reload.  A complete  dump  is  usually  divlaeo  Into 
sections,  one  of  Mhich  contains  all  system  files.  These 
system  files  are  relcadeo  first  by  the  initializer.  Next, 
the  anSMering  service  is  started  so  that  other  system 
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daeaons  can  ba  logged  In  to  perfora  the  remainder  of 
reloading.  The  retriever  daemon  can  be  used  for  this 
purpose  since  it  Mill  have  the  necessary  privileges. 


3.14  OPERATOR  INTERFACE 


3*14.1  New  Procedures  and  Responsibilities 

Relatively  few  changes  to  the  Multics  ooerator  interface  are 
anticipated.  The  operators  will  be  given  the  new 
responsibility  of  reassigning  cevice  classifications.  Also, 
tape  handling  will  be  somewhat  different.  Tape  drives  and 
tape  reels  will  be  identified  by  color-coded  classification 
labels.  Each  registered  tape  reel  will  have  sn  associated 
three-letter  authentication  cooe  to  be  typed  by  the  operator 
at  tape  mount  time  for  verification  purposes. 


3«14.2  Security-Related  Messages 


Security-related  messages  directed  to  the  operator  will 
explicitly  specify  violations*  warnings*  etc.  so  that 
appropriate  operator  action  can  be  taken.  S ch  messages 
will  be  distinguished  by  some  convention,  e.g.  orececing 
asterisks.  Also,  the  audible  alarm  on  the  operator's 

console  will  be  used  to  alert  the  operator  whenever  his 
attention  is  required. 
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3.15  ADMINISTRATIVE  CONTROL 


3.15.1  Requirements 

The  functions  of  the  System  Administrator  (SAJ  and  System 
Security  Officer  (SSO)  must  be  as  distinct  as  possible.  The 
SA  must  not  be  able  to  downgrade  segments*  nor  assign 
classifications  to  new  users*  nor  change  the  classification 
of  existing  users.  The  SSO  must  not  be  required  to  register 
new  users  nor  perform  accounting, 
i 

I 3.15.2  Oeslgn  Considerations 

t 

j The  primary  c ons ider a 1 1 on  is  that  the  authority  of  the  SA 

’ and  SSO  be  clearly  delineated.  In  this  way*  the  SA  will  net 

be  able  to  perform  functions  which  are  the  responsibility  of 
the  SSO*  and  the  SSO  will  not  be  buroened  by  the  routine 
v tasks  of  the  SA.  A seconoary  consideration  is  that  the 

\ tools  for  use  by  the  SSO  shout c be  simple  ano  easy  to  use* 

' and  should  follow  normal  Hultics  command  conventions. 

| 

i 

j 3*  1.5.3  Chosen  Approach 

The  SA  <114  1 

| 1.  register  all  users* 

i 

!(  2.  perform  system  accounting  functions? 

3.  perform  default  project  aom  inistrat ion. 

> 

In  general*  the  tasks  of  the  SA  will  remain  ut  -hanged  in  the 
**  new  system. 

..*?  The  SSO  wllli 

1.  assign  clearances  to  persons  and  projects*  and  assign 
classifications  to  terminals  and  I/O  devices? 

2.  assign  the  mnemonics  for  levels  and  categories? 


3.  perform  the  downgraoe  functions  on  segments 
d i r ec  t or  i es  ? 


and 


4.  be  responsible  for  the  ohyslcal  security  of  all  on-site 
and  remote  equipment,  ircludlng  the  integrity  of 
interconnecting  cables; 

5.  be  able  to  force  a given  user  (or  all  users)  to  change 
his  password! 

6.  receive  and  review  all  security  audit  data! 

7.  approve  retrieval  requests  (see  Section  3.1?)* 

8.  fix  security-related  inconsistencies  detecteo  by  the 
salvager  (see  Section  3.131 ! 

9.  set  the  security  aualt  flags  for  various  oersonid’s  and 
pro|ectid*s  (See  Section  3*16.4). 

The  special  commands  (e.g.  downgrade)  used  by  the  SSO  will 
contain  calls  to  auditing  procedures  to  record  their  usage. 
It  Is  also  suggested  that  the  console  script  of  the  SSC  be 
retained  as  further  auditing  Information. 

Those  privileged  functions  which  must  be  restricted  to  the 
SSO  alone  will  be  Implemented  via  a separate  gate  segment. 
In  this  way,  the  ACL  on  the  gate  segment  can  effective  I*  be 
used  to  give  access  to  the  SSO  while  denylrg  it  to  other 
users.  The  user  ring  functions  (commands  for  inspecting  the 
audit  data,  and  setting  the  clearances  of  persons  and 
projects)  which  are  restricted  to  the  SSO  will  similarly  be 
protected  by  their  ACL. 

The  tables  which  are  shareo  between  the  SSO  ana  SA  are 
updated  only  by  the  system  control  process,  ano  the  updating 
tools  will  be  modified  to  permit  only  the  SSO  to  set  the 
per-person  clearances  ano  audit  flags  in  the  PNT  ana  the 
pei — project  clearances  ano  auoit  flags  in  the  SAT.  In  this 
way,  the  existing  functions  of  the  SA  will  not  bp  affected, 
and  the  SSO  will  assume  control  of  all  security-related 
fun-r  1 1 ons. 

Several  new  tables  will  be  the  exclusive  responsibility  of 
the  SSO,  including  the  Peripheral  Control  Table  speclfyirg 
the  I/O  channel  classifications  and  the  terminal  answerback 
codes. 


3.16  SYSTEM  AUOIT 


3.16.1  Requirements 

The  system  audit 
normal  and  abnormal 
regular  security 


5200.28-M) . 
are! 


functions  should  orovide  e history  of 
system  use.  or  operation.  to  permit 
review  of  system  activity  (per  OoO 


System  events  to  be  included  in  the  audit  aata 


1.  each  access  to  a classified  file  and  the  nature  of  the 
access  (per  OoO  5200.28-N). 

2.  each  login  and  logout; 

3.  each  unsuccessful  login  attempt  and  reason  for 
rejection. 

4.  each  relected  access  to  information  due  to  security 
restrictions  and  each  illegal  attempted  use  (fault)  of 
access  permission; 

6.  all  system  faults  which  could  indicate  attempts  to 
subvert  the  system  or  to  exploit  hardware  failures? 

6.  all  security  related  actions  of  the  System  Security 
Officer  or  the  System  Administrator ; 

7.  each  time  3 process  awards  itself  extra  privileges? 


8.  ail  completed  requests  for  printed  or  punched  output 
(not  terminal  output). 

9.  all  tape  mount  requests  for  user  tapes. 

where  possible.  the  recording  of  audit  data  must  have  the 
capability  of  being  turned  off  on  a per  user  or  oer  system 
basis.  The  subverter  process,  for  example,  must  be  known  t<> 
the  audit  programs  so  that  its  known  violations  can,  if 
desired,  be  omitted  from  the  audit  data.  Oata  reduction 
programs  must  be  provided  to  preoare  summaries  of  audit  oata 
for  inspection. 


3 • 16.2  Design  Considerations 


Audit  data  segments  must  be  wrlteable  by  many  processes* 
hence,  there  must  be  a locking  strategy  provided  with 
assurance  that  the  process  locking  the  data  will  unlock  it 
before  it  loses  eligiblity.  These  segments  must  either  fall 
outside  the  security  rules*  or  there  must  be  a oata 
segment(s)  for  each  leve i/cate  gory  combination  used  on  the 
system . 

Ring  zero  auditing  eust  be  done  only  when  there  is  no 
directory  locked  by  the  sub|ect  process  to  avoid  deadlocking 
prob I ems. 

The  feasibility  of  storing  exponentially  smoothed  data  on 
the  interval  between  certain  events  will  be  examined  (e*g. 
average  period  of  illegal  opcode  faults*  average  oerloe  of 
initiate  rejection  due  to  security)  3fter  more  design 
details  are  known  and  an  assessment  of  performance  impact 
can  be  made. 

3*16.3  Design  Apbroach 

Each  successful  login  is  recorded  on  the  system  control 
console  output*  as  well  as  lr  the  online  log  kept  by  the 
answering  service.  This  log  also  records  each  unsuccessful 
login  attempt  and  the  reason  for  rejection.  The  mechanism 
which  records  information  in  this  log  will  be  modified  to 
ensure  that  tne  following  oata  will  be  recordeo  for  each 
unsuccessful  login! 

login  line  as  entered  by  user 
hardware  channel  of  the  terminal 
answerback  code  ot  the  terminal 
maximum  level  of  the  terminal 
the  reason  why  the  user  was  rejected 
date  and  time 

In  addition*  if  the  person's  clearance  is  less  than  the 
maximum  "level"  of  the  termiral*  a "breach  of  physical 
security"  message  will  be  sent  to  the  operator.  Also,  if 
the  number  of  bad  oassworos  for  a given  pertonid  is  greater 
than  the  system  maximum*  an  "attempted  breach  of  security" 
message  will  be  sent  to  the  operator  and  recoroed  in  the 
log.  This  count  will  be  reset  on  the  next  successful  login 
ot  that  person. 

All  special  commands  provided  for  the  System  Security 
Officer  to  maintain  security  control  will  provide  audit  of 
their  use.  This  data  will  be  protected  by  the  ring 

mechanism,  However,  the  data  can  only  be  assumed  to  be 
complete  If  the  security  related  function  arc  its  auoit  is 
performed  in  a lower  ring  than  the  System  Security  Officer 
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would  log  into.  Otherwise*  a person  togging  in  as  the 
System  Security  Officer  could  write  a program  which  would 
perform  the  sane  security  related  functions  without  using 
the  the  audit  Interface.  The  details  of  which  security 
functions  must  be  performed  entirely  within  the  user  ring 
will  be  described  when  the  implementation  details  are  better 
unders  food. 

The  granting  of  special  access  privileges  to  any  process 
will  be  audited  by  ring  0. 

Any  rejected  attempt  to  add  a segment  to  a user's  aodress 
space*  due  to  security  rules*  will  be  audited  by  ring  0. 
(Shared  data  and  locking  problems  will  occur  here). 

All  access  violation  ana  illegal  opcode  faults  will  be 
audited  by  ring  0*  The  data  recorded  for  each  fault  audited 
wi 1 1 incl udet 

pathname  and  offset  of  object  denied  access 
type  of  violation  (fault) 

"level"  of  ob|ect 

user's  effective  access  mode  to  the  object 
"level"  of  process  anc  current  ring 
pathname  of  executing  procedure 
user  ID  of  process 
date  and  time 

(Shared  data  and  locking  problems  will  occur  here). 


The  classified  segment  audit  data  will  include> 

user  10  of  process 
patnname  of  the  segment 
"level"  of  the  segment 

user's  effective  access  mode  to  the  segment 
date  and  time 

This  capability  may  introcuce  significant  performance 
degradation  in  the  system  ano  will  generate  a large  amount 
of  audit  data  (shared  data  and  locking  problems  occur  here). 


The  problems  of  shared  data  and  locking  are  primarily  a 

problem  associated  with  rings  other  than  ring  0.  The  audit 

data  areas  must  be  writable  by  all  processes  if  the 

information  is  to  be  complete.  This  cannot  be  done  in  the  j 

outer  rings  without  allowing  a user  process  to  viol cte  the 

fixed  level  property.  Even  if  this  was  allowed*  a process  • 

can  lose  its  eligibility  to  use  a processor  while  executing  , 

in  an  outer  ring  with  a lock  set  which  could  cause  other 

processes  to  wait  for  the  locking  process  to  be  reschedu I eo.  j 
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Therefore*  all  aucltlng  Mill  be  handled  by  ring  0 procedures 
since  this  is  the  only  ring  in  which  all  processes  can  write 
in  common  data  areas*  regardless  of  clearance*  without 
explicitly  violating  the  fixed  level  property  ano  since 
processes  executing  ir  ring  o are  guaranteed  to  complete  all 
operat ions  which  must  be  performed  while  a loch  is  set. 

The  mechanism  to  be  usea  for  the  ring  0 auditing  will  be  an 
enhanced  version  of  the  system  error  auditing  procedure. 
This  has  the  advantage  of  providing  a common  interface  for 
all  system  auditing  functions.  The  audit  data  will  be 
stored  in  a special  dish  partition  and  periodically  copied 
into  segments  in  the  the  Multics  storage  system  by  the 
system  control  process.  The  error  type  labels  on  each  audit 
entry  will  be  used  to  separate  the  security  related  entries 
from  other  system  errors. 

A ring  0 entry  will  be  provided  to  allow  administrative  and 
: security  related  procedures  to  record  their  actlors  as 

needeo.  Access  to  this  gate  should  be  provided  for  all 
j users,  but  limitea  to  rings  of  higher  privilege  than  the 

» normal  user  ring  tc  avoid  a potential  source  of  sabotage 

through  flooding  the  audit  data  with  irrelevant  entries. 

} 

The  log  of  printed  ana/or  punched  output  will  be  the  file  of 
J accountability  forms  and  an  online  copy  of  the  information 

printed  on  the  driver  control  console.  User  terminal  output 
I will  not  be  logged.  The  system  control  console  output  and 

1 the  system  log  data  will  provioe  the  needed  audit  data  for 

j important  system  events  not  recorded  elsewhere. 

| The  allocator  process  that  handles  tape  drives  will  provioe 

a log  o"  all  tape  requests*  including  denied  requests. 
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3.16.4  Audit  Selectivity 

AM  processes  will  be  treated  the  same  by  the  audit  system. 
The  ring  zero  portion  of  the  audit  system  will  checK  the  pcs 
of  a process  to  determine  whether  a given  event  shoulc  be 
Included  in  the  audit  data.  This  will  provide  a wide  range 
of  selectivity  to  the  audit  system. 

The  audit  flags  in  the  pds  will  be  established  at  process 
creation  time.  Another  data  field  will  be  acded  to  each 
entry  in  the  PNT  and  SAT  which  will  describe  the  events  to 
be  audited  for  each  personid  and  projectld.  At  process 
creation  time,  the  system  control  process  will  turn  on  the 
pds  audit  flags  if  the  corresponding  flag  appears  for  the 
personid  or  projectid  of  the  user. 
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Only  th«  SSO  **111  be  able  to  turn  off  these  flags  in  the  PNT 
and  SAT.  The  default  value  Mill  be  "on**  for  each  ne*>  person 
or  project  registered  by  the  System  Administrator. 

The  events  Mhich  Mill  be  identified  by  separate  audit  flags 
Mill  Include  the  folloaingt 

access  to  classified  segments* 

security  related  file  system  errors* 

aearding  of  special  access  privileges* 

illegal  opcode  faults* 


access  mode  related  access  violation  faults* 


) 


i 

i 

i 
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ring  related  access  violation  faults* 
audit  calls  from  outer  rings* 

other  events  identified  during  implementation. 

It  is  recommended  that  the  audit  flags  normally  be  turned 
off  for  the  AFOSC  supplied  subverter  process*  since  it  **111 
only  ado  noise  to  the  audit  data.  Homever,  or  occasion*  it 
may  be  desirable  to  audit  the  subverter  process  as  an  ale  in 
testing  the  audit  system  itself. 


16.5  Audit  Oata  Reduction 

A simple  data  reduction  and  output  formatting  program  Mill 
be  provided  to  prepare  audit  data  for  Inspection.  For  each 
class  of  audit  data,  the  program  mill  recognize  KeyMorcs 
corr esDond ing  to  fields  in  the  audit  data,  such  as  "segment 
name,"  '•userid,"'  "error  code*"  etc.  The  user  of  the  oata 
reduction  program  (presumably  the  SSOI  Mill  supply  a list  of 
keywords  and  corresponding  data  items.  For  example*  if  the 
user  specifies  “error  code!  no  access,"  all  entries  in  the 
Indicated  audit  data  tile  will  be  printeo  for  which  the 
error  code  field  specifies  "no  access."  A limited 
capability  for  the  use  of  "AND*  "OR,"  and  "NOT"  Boolean 
operations  Mill  De  supporteo  to  enhance  selectivity.  The 
flle_output  command  can  be  used  to  direct  output  to  a 
segment. 


3.17  CONTROL  AND  AUOIT  OF  SYSTEM  CHANGES 


3«l7.i  Requirements 

Security  con f i gur at i or  control  ensures  that  all  changes  to 
the  operating  system  are  accounted  for  and  verifies  that 
these  changes  do  not  imoare  the  security  of  the  system. 


Procedures  must  be  established  to  control  ana  auait  system 
changes.  Software  tools  must  be  provided  to  assist  in  the 
audit.  All  security  sensitive  nodules  should  be  identified 
in  each  release.  Source  and  object  code  have  been  croviaed 
for  the  initial  release.  Source  and  object  coce  must  t>e 
provided  for  all  revisions  along  with  a listing  of  all 
modules  modified  and  the  reason  for  each  modification  within 
each  module. 


3.17.2  New  Release  Material 

For  each  new  release,  will  contain  at  least! 
A Multics  system  tape  (MST»; 


Machine  readable  source  code  of  all  modules  charged 
from  Multics.  80S.  Salvager*  and  OATANET  355  systems? 


BOS  and  Salvager  object  tape  if  the  code  nas  been 
changed? 

OATANET  355  object  cooe  if  changed? 

Object  code  of  all  compilers,  assemblers.  ana  PL/I 
operators  used  to  generate  the  changed  mocules? 

List  of  all  modules  changed  with  the  reason  fo~  the 
change. 


3.17.3  Tools 


Procedures  will  be  sucplieo  to  assist  in  comparison  and 
auditing  of  system  changes  at  source  and  object  level.  An 
ASCII  comparison  procedure  will  be  supplied  to  aid  in  noting 
changes  made  to  source  code.  A procedure  which  makes  a 
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all  inter-procedur • calls  Mill  be 
task  of  system  auditing.  81nary  word 
comparison  procedures  Mill  be  supplied  to  atloM  comparison 
of  object  tapes  anc  online  object  code.  Procedures  to 
generate  and  check  MS Ts  Mill  also  be  supplied. 
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3.17.4  Recommended  Procedures 

The  security  conf iguratlon  control  procedures  are  designed 
to  give  the  maximum  confidence  that  the  system  remains 
secure  Mhile  modifications  and  improvements  are  made. 
Recommended  proceoures  involve  auditing  botn  the  source  code 
and  the  ob|ect  code  oroduced  by  the  source. 

The  Air  Force  should  maintain  a protected  set  of  source  and 
oblect  code  tapes  for  use  as  a standard  of  comparison.  Each 
new  release  should  be  audited  at  the  source  level  to  match 
all  source  changes  m! th  the  list  of  changes  and  to  verify 
the  reason  for  the  change*  The  source  cooe  should  be 
independently  compiled  or  assembled  and  the  result  audited 
against  the  delivered  obiect  code  to  detect  discrepancies  in 
compilers  or  assemblers.  Any  deviation  should  halt  the 
installation  until  it  is  satisfactorily  resolved.  The 
recommended  procedure  1st 


1.  compare  the  supplied  source  code  against  the  protected 
standard  source. 

?.  match  all  differences  against  the  list  of  mooified 
modu I esi 

3.  verity  that  the  source  changes  are  reasonable  to 
accomplish  the  change  specified;. 

4.  verify  that  the  source  changes  do  not  adversely  affect 
security  controls; 


5.  prepare  a test  system  by  editing  the  standard  source  to 
incorporate  the  audited  changes* 

6.  compare  the  ob|ect  code  of  the  test  system  Mith  the 
object  code  supplied  by  Honeymel  I • 


7. 


generate  a system  tape  using  the  test  system 
compare  it  against  the  tape  supplied  by  Honeywell. 
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8. 


install  the  test  system  on  a trial  basis  and  perform 
quality  control  and  security  verification? 


9.  accept  and  install  the  system? 
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3.18  THE  MULTICS  CCOS  ENVIRONEMEM 


3 • 1 8 • 1 Requirements 

Use  of  the  GCOS  Environment  in  a user's  process,  or  use  of 
the  GCOS  Daemon  on  the  system,  must  not  comcromise  any  of 
the  Multics  access  control  mechanisms,  or  any  of  the 
assumptions  made  as  a part  of  the  design  analysis. 


3.18.?  Design  Considerations. 

i Use  of  The  GCCS  Daemon  invalicates  the  assumptions  that  all 

I users  of  Multics  are  known  to  the  system,  are  validated 

‘ interactively  with  name  and  password  at  login,  ard  are 

I benign.  The  GCOS  daemon  requires  no  passworo  and  no 

’ interactive  authentication  before  it  submits  an  absentee  Job 

whose  principal  identifier  is  the  name  of  the  user  founo  on 
j the  GCOS  Job  oeck.  This  rules  out  use  of  the  GCOS  Daemon, 

v eliminating  the  principal  motivation  for  creating  it  (which 

| was  to  eliminate  the  online  verification  of  identity). 

j Use  of  the  GCOS  Oaemon  “anonymously**  (with  all  GCOS  Jobs 

| being  run  under  fne  sate  Multics  principal  identifier, 

j “anonymous. GCOS. m" ) would  have  given  very  little  accounting 

I information,  and  would  have  presented  even  more  access 

i problems,  since  each  GCOS  Job  would  have  had  full  access  to 

* every  other  GCOS  Job’s  segments.  Since  anonymous  use  of 

j GCOS  would  have  violated  the  "benign  environment**  assumption 

) stated  in  Section  3*1*3*  it,  too,  has  been  ruled  out. 


3.18.3  Chosen  Approach 

& 

The  identity  of  each  GCOS  job  oeck  will  be  validated  online 
by  assigning  each  person  who  wishes  to  run  GCOS  Jobs  on 
Multics  their  own  Multics  userid.  To  submit  a GCOS  Job  they 
will  login  normally,  queue  a request  to  read  in  the  cards, 
and  then  either  execute  the  GCOS  command  In  their 
interactive  process,  or  submit  an  absentee  Job  to  oo  it. 

The  GCOS  Oaemon  will  not  be  used. 
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4.0  QUALITY  ASSURANCE 


This  section  coes  not  apoly  to  this  report, 


6.0  NOTES 


This  section  Is  for  Administrative  Information  Only  - Not 
Contractually  Binding. 


6.1  Removable  Media 

Ourlng  the  Oesign  Analysis*  the  security  recuirements  for 
integrating  removable  media  storage  into  the  virtual  memory 
was  discussed.  The  term  "demountable  segments"  has  been 
used  in  this  section  to  differentiate  removable  media 
containing  portions  of  the  Mul tics  storage  system  from 
removable  media  associated  with  I/O  directed  from  a Multics 
process. 

The  recommendations  resulting  from  the  Design  Analysis 
discussions  are  included  in  this  section  because  they  are 
not  a direct  part  of  the  Implementation  of  security 
controls.  However*  the  following  recommendations  will  ba 
used  as  guidelines  by  the  project  which  is  designing  the 
demountable  segment  capability  for  Multics. 


6*1.1  Recommendations 

1.  The  demountable  segment  capability  must  allow  the  basic 
Multics  access  controls  to  be  extended  to  removable  storage 
media.  OlsK  packs  are  the  primary  type  of  media  addressee, 
as  the  value  of  tapes  in  this  role  is  not  operationally 
clear  at  this  time. 

2.  Each  physical  disk  pack  must  be  identified  as  part  of  the 
system,  such  that  it  should  be  impossible  for  it  to  be  used 
by  any  process  for  direct  I/O. 

3.  There  must  be  a unique  machine  readable  header  on  each 

physical  unit.  No  disk  oack  should  be  usable  for 

demountable  segments  until  the  header  has  beer  initialized 
by  the  system.  This  header  should  identify  the  highest 
classification  of  Information  ever  stored  on  the  disk  each. 
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4.  The  classification  identified  in  the  header  should  be  used 
by  the  system  to  decide  where  to  store  segments  which  are  to 
be  moved  to  removable  media. 

Basically.  a minimum  ano  maximum  classification  must  be 
assignea  to  each  oevice  to  determine  the  range  of  levels 
that  can  be  stored.  However.  to  avoid  a potential 
write-down  path,  the  maximum  and  minimum  must  be  equal. 
Otherwise.  the  presence  or  absence  of  a disk  pack  at  the 
time  a segment  is  referenced  could  be  taken  as  Information 
from  process  with  a higher  clearance. 

5.  The  information  on  the  removable  media  should  be  of  the  same 
format  for  segments  and  directories  as  all  other  media  used 
by  the  system. 

6.  The  user  who  wishes  to  group  segments  on  the  same  media  must 
put  them  ail  in  the  same  subtree  of  the  storage  system, 
since  it  only  makes  sense  to  group  by  subtree  if  part  of  the 
hierarchy  is  to  be  removed  (i.e.  all  parts  of  the  path  must 
be  online  to  make  a reference). 

7 . Th''  allocation  of  storage  must  be  totally  maraged  by  the 
operating  system  as  well  as  the  exact  time  of  movement 
to/from  demountable  media. 

a.  The  means  of  requesting  information  from  demountable  media 
must  be  studied  further.  It  would  be  nice  for  a user  to 
pre-specify  that  a given  demountable  subtree  will  be  neeceo, 
however  , no  operator  should  initiate  the  loading.  Only  the 
system  must  be  able  to  manage  tht  usage  of  the  media. 

9.  The  pnysical  labeling  instructions  (to  be  attached  to  the 
media)  must  be  supplied  to  the  operator  by  the  system  for 
all  new  media  initialise  by  the  system. 

10.  All  media  used  for  demountable  segments  Must  be  physically 
protected  with  the  same  care  as  the  remainder  of  the  system. 
This  media  must  never  be  trusted  if  removed  from  the  ares  of 
the  system. 


6.2  Message  Segments 

An  alternative  approach  (which  has  been  rejected  by  t re  Air 
Force)  would  have  allowed  security  rules  to  be  enforced  in 
ring  l rather  than  ring  0.  In  this  scheme,  ring  0 would 
grant  read  and  write  access  for  message  segments  to 
orocesses  of  all  clearances.  Each  individual  message  stored 
in  a message  segment  would  be  "classified’*  by  the  msf  at  the 
clearance  level  of  the  sending  crocess.  The  msf  would  only 
permit  extraction  of  a message  by  a process  having  a 
clearance  higher  or  equal  to  the  c I ass  1 f ic at  i or  of  the 
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